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

[Rob Meijer]

On Sun, November 25, 2007 08:45, Crispin Cowan wrote:
>
>> If you have a program that does not need to pass FDs across execve()
>> (other than stdin/stdout/stderr), you could change its execve() call
>> to close any offending FDs (perhaps logging a warning) or halt with an
>> error if there are any offending FDs.  Again, that can be done in the
>> kernel or in glibc.
>>
> This is essentially what I propose: if the profile for a program does
> not permit implicit delegation, the it closes the FDs on exec() whether
> that was specified or not. But we can do that in AppArmor policy by
> making FD delegation selectable, rather than by changing the programs or
> libraries.
>

Agreed, but if you could combine this with defining a way to do explicit
delegation through execve, and could make AppArmor aware of that, it would
IMO be a bit cleaner.
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, one working in userspace completely
that doesn't need to interact with AppArmor, and one that is implemented
mostly by AppArmor. This way developers not working on systems that use
AppArmor would be able to plug their potential holes, but AppArmor would
be able to make the distinction between programs that need to be protected
from their self and programs that don't.)

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.


Rob