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

[David Hopwood]

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.

-- 
David Hopwood