Supplemental Groups

[Chris Wright]

* Klaus Weidner (klaus at atsec.com) wrote:
> On Tue, Feb 22, 2005 at 10:02:55AM -0800, Casey Schaufler wrote:
> > --- Chris Wright <chrisw at osdl.org> wrote:
> > > I don't know, I don't think it's explicitly required by CAPP (unless
> > > you interpret subject identity to include suplemental group IDs).
> > 
> > If the suplemental group information is used to make access control
> > decisions it needs to be in the audit record. Same with the
> > capabilities.
> 
> 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, ..."

> LSPP adds a requirement that the "sensitivity labels of subjects,
> objects, or information involved" be included in each audit record
> (that's the MAC information), this does not include any DAC information
> such as group membership or ACLs.

I don't think it's reasonable to expect to track which bit let you
access the file, but it is reasonble to consider dumping the 'subject
identity' as defined by uid's, gid's (including supplemental groups),
capabilities (and with LSPP clearly labels).

> 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.

> Capabilities are different, this could be considered to be covered by the
> "use of the rights of a role" requirement for FMT_SMR.1. The existing
> Linux security targets had not made any fine-grained role distinctions
> based on capabilities, they have used the simplified "administrator ==
> UID 0 == all capabilities" model which makes it sufficient to record the
> effective UID. If you have an ST that identifies distinct roles based on
> individual capability bits, you would need to audit the current
> capabilities of the process. Note that the audit requirement for CAPP and
> LSPP is that "the role and the origin of the request" be included in the
> record.

Already some userspace apps drop capabilities.

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