[cap-talk] [Apparmor-dev] Re: execve() and CLOEXEC
david.hopwood at industrial-designers.co.uk
Sun Nov 25 12:06:09 EST 2007
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
More information about the cap-talk