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

[Rob Meijer]

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, 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);
>
> The convention for other *at functions is that setting the directory fd
> argument to AT_FDCWD indicates the current directory. So safe_execve is
> redundant:
>
> int safe_execve(const fd_set *keepset, int dirfd, const char *filename,
>                 char *const argv[], char *const envp[]) {
>     return execveat(keepset, AT_FDCWD, filename, 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.
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.

For the 'safe' execve variants, no external policy would be needed at al,
other than allow all explicit delegation, as the keepset would make
delegation 'explicit', and would by this already set the policy for all
non designated Fd's to 'dont delegate' or 'close on exec'.

Rob.