[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [RFC] linux-2.6.10-auditfs-tc1.patch

* Steve Grubb (sgrubb redhat com) wrote:
> On Monday 24 January 2005 11:57, Casey Schaufler wrote:
> > If I have 6 capabilities but only need one
> > of them to perform an action the process list
> > does not identify the policy that is being
> > overridden.
> Maybe this is a wording issue. In Linux, you start with capabilities and lose 
> them. You cannot override.

Yeah, that's _mostly_ true.  You have multiple sets.  The effective set
is what is checked against.  But the permitted set may be larger than the
effective set, in which case you could raise caps if you've momentarily
dropped one.  Granted, not much of this is ever used.

> > If I need 2 capabilities but only 
> > have one, the one that I don't have but needed
> > needs to be pointed out. 
> I can see this being useful when writing software, but production systems 
> should have the capabilities set correctly at installation.

Yes, it's critical during developement and QA.  Of course, you can
always get something to say directly...$pid wanted $cap.  SELinux does
this now, for example.  Didn't think it was needed for something like
CAPP compliant audit records though.

> > The capabilities required to perform an action will not 
> > be sent in concrete. For example, accessing
> > /a/file may require different capabilities depending on 
> > the mode of /a.
> We are talking about posix capabilities, right? They are bound to a process 
> and enforced on a syscall by the kernel. That *is* cast in concrete unless 
> you hack the kernel sources.

Well, something like chmod -w file, will make a difference.  I assume
that's what Casey's getting at.

Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]