Casey Schaufler <[EMAIL PROTECTED]> wrote:
> Whoops, sorry. You leave the process label alone and explicitly
> set the file label using the xattr interfaces.
That's the wrong way to do things. There'd then be a window in which
cachefilesd (the userspace daemon) could attempt to view the file whe
On Mon, 2007-08-13 at 14:44 -0700, Casey Schaufler wrote:
> --- David Howells <[EMAIL PROTECTED]> wrote:
>
> > Casey Schaufler <[EMAIL PROTECTED]> wrote:
> >
> > > The specification of your push interface that the push operation
> > > not affect how others access the process is OK for SELinux, bu
On Tue, 2007-08-14 at 08:53 -0700, Casey Schaufler wrote:
> --- David Howells <[EMAIL PROTECTED]> wrote:
>
> > Casey Schaufler <[EMAIL PROTECTED]> wrote:
> >
> > > With Smack you can leave the label alone, raise CAP_MAC_OVERRIDE,
> > > do your business of setting the label correctly, and then dro
--- David Howells <[EMAIL PROTECTED]> wrote:
> Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
> > With Smack you can leave the label alone, raise CAP_MAC_OVERRIDE,
> > do your business of setting the label correctly, and then drop
> > the capability. No new hooks required.
>
> That sounds like a
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> With Smack you can leave the label alone, raise CAP_MAC_OVERRIDE,
> do your business of setting the label correctly, and then drop
> the capability. No new hooks required.
That sounds like a contradiction. How can you both leave it alone and set it?
Serge et al.,
I believe the attached patch addresses your concerns.
Cheers
Andrew
Serge E. Hallyn wrote:
> How about just defining CAP_BSET_INIT once in include/linux/capability.h
> depending on CONFIG_SECURITY_FILE_CAPABILITIES, and at
> kernel/capability.c changing
> kernel_cap_t cap_b
