Supplemental Groups

Chris Wright chrisw at osdl.org
Wed Feb 23 17:52:08 UTC 2005


* Klaus Weidner (klaus at atsec.com) wrote:
> On Wed, Feb 23, 2005 at 09:07:31AM -0800, Chris Wright wrote:
> > * Klaus Weidner (klaus at atsec.com) wrote:
> > > Sorry to disagree once again, but auditing the reasons for access control
> > > decisions isn't required by CAPP anywhere, see section 5.1.1.2 and table
> > > 1 for the exhaustive list of audit record requirements. It just needs to
> > > record the success/failure result of the operation.
> > 
> > It's a matter of interpretation of 5.1.1.2 a) "... subject identity, ..."
> 
> Since "subjects" are defined to be processes (running on behalf of
> users), I'd consider them to be identified by the PID, and the security
> attributes would be properties of the process but not part of the
> identity. (A privileged process may change its own security properties,
> and I'd think it would be weird if that would correspond to a change of
> identity for that process.)

OK, I had always considered security attributes to be part of the
identity.  Thanks for clarification.

> > > I agree that having this type of information in the audit records would
> > > be useful, but doing it right would need many changes to the OS and goes
> > > beyond what CAPP/LSPP require.
> > 
> > It's simple to add the info without including which allowed you to access
> > the object.  I agree, we aren't going to track which key let you in.
> 
> Agreed, including that information would be useful, even if CAPP doesn't
> directly require it.

Well, let's see if there's any trouble with dumping them (since they are
variable length).

> > Already some userspace apps drop capabilities.
> 
> Okay, but it's only security relevant from the CC point of view if the
> security target actually makes a distinction based on capabilities.
> Voluntarily giving up rights isn't interesting if you don't make claims
> that this increases security. Adding additional capabilities would be
> security relevant, but currently this simply causes the application to be
> considered a trusted process, same as a standard suid root process.

Ah OK, that makes sense.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net




More information about the Linux-audit mailing list