[cap-talk] [Apparmor-dev] Re: execve() and CLOEXEC

[David Hopwood]

Rob Meijer wrote:
> On Sun, November 25, 2007 16:07, David Hopwood wrote:
>> Rob Meijer wrote:
>>> To me the ideal solution would leave an application programer with 4
>>> versions of execve:
>>>
>>> The normal unsafe one:
>>>   int execve(filename,argv,envp);
>>>
>>> A quick fix one for plugging the fd leackage hole on existing programs
>>> and for allowing new programs to avoid such problems:
>>>
>>>   int safe_execve(fd_set *keepset,filename,argv,envp);
>>>
>>> (We could make two versions of this one, [...])
>>>
>>> And two aditional ones for programs that would be fully written to take
>>> advantage of Fd delegation.
>>>
>>>   int execveat(fd_set *keepset,int dfd,relpath,argv,envp);
>>>   int fdexecve(fd_set *keepset,int exefd,argv,envp);
[...]
>>> If AppArmor would than apply policies only to the first one,
>>> (with a default of allow stdin/strout/stderr), I feel we would
>>> end up having the best of both worlds.
>>
>> Having security policies differ in non-obvious ways according to which
>> of several similar interfaces is used, sounds error-prone to me.
> 
> The problem that a policy would be trying to address would be the non
> intended leackage of open Fd's on exec, that arise from the fact that
> all Fd's are passed implicitly unless they are all individualy marked
> for close on exec.
> 
> Given that the policy would be used to define how to handle 'implicit'
> delegation of Fd's, the normal execve would be the only one to what
> such a policy would make sense.

OK, that's fine. I misunderstood what the referent of "the first one" was.

> Given that a default policy of 'deny all' (including stdin/stdout/stderr)
> would imply almost any program using execve would need a policy to permit
> stdin/stdout/stderr to be passed, a default allowing just these 3 may seem
> to be more practical.

It seems that you only need two application-specific policies:
 - execve leaves only stdin/stdout/stderr open (safer default)
 - execve leaves all fds open (for backward compatibility or strict POSIX
   compatibility).

-- 
David Hopwood