Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Stephen Smalley (sds@xxxxxxxxxxxxx):
> On Thu, 2006-08-17 at 08:00 -0400, Joshua Brindle wrote:
> > Stephen Smalley wrote:
> > > On Tue, 2006-08-15 at 21:42 -0500, Serge E. Hallyn wrote:
> > >   
> > > <snip>
> > >> Very good point.  Preventing communication channels i.e. through signals
> > >> isn't a concern, but user hallyn ptracing himself running /bin/passwd
> > >> certainly is.
> > >>     
> > >
> > > Actually, ptrace already performs a capability comparison (cap_ptrace).
> > > Wrt signals, it wasn't the communication channel that concerned me but
> > > the ability to interfere with the operation of a process running in the
> > > same uid but different capabilities, like stopping it at a critical
> > > point.  Likewise with many other task hooks - you wouldn't want to be
> > > able to depress the priority of a process running with greater
> > > capabilities.
> > >
> > >   
> > On this point, what about environment tampering of processes with caps? 
> > LD_PRELOAD=my_bad_lib.so /usr/bin/passwd. glibc atsecure logic would 
> > have to be updated to do a capability comparison.
> 
> That's the bprm_secureexec logic change that has already been mentioned;
> that determines the AT_SECURE value, and glibc then just acts based on
> that value provided by the kernel.  Just a matter of extending
> cap_bprm_secureexec to compare the capability sets.  Already on Serge's
> todo list, but it is necessary for this to be a safe change, and should
> happen before this patch goes anywhere (even -mm), IMHO.

Does the following seem a reasonable way to handle secureexec in the
face of file caps?

Seems like it should work so long as we don't have to worry about the
bprm changing partway through exec.  This should avoid the need to store
the old capabilities.

Unless I've got my head screwed on completely backward...

thanks,
-serge

(note - Still need at least a signals patch on top of this before the
file caps could be safe for use)