LSPP Requirements -- first pass

[Casey Schaufler]

--- Chris Wright <chrisw at osdl.org> wrote:

> * Amy Griffis (amy.griffis at hp.com) wrote:
> ... Hmm, I'd imagine this
> should include
> capabilities as well.  Similarly for inode, socket,
> ipc...

The rule of thumb that seems to make evaluators
happy is that you should include sufficent
information that the reasons for a failure or
a success can be determined from the record.
Thus, if the operation succeeded only because
you had a capability the capabilities need to
be included. If you failed an operation due to
mod bits, you need the process' uid, group set,
and capabilities, and the file's mode and acl.
Ideally you should include a list of the
capabilities that you checked for, but didn't
have, in the case here CAP_DAC_READ.

> > Additionally, user attributes will now include the
> SELinux user
> > identity and SELinux role.  Is there ever a need
> to include that
> > information in audit records generated by the
> audit subsystem?  Or
> > will all events requiring that information be
> logged by SELinux?
> 
> All current audit records (i.e. CAPP style) which
> require logging
> subject/object, now simply have expanded notion of
> subject/object
> (i.e. relevant labels).  Certainly, this includes
> those generated from the
> audit subsystem, which simply needs to query
> security module to get label.
> I suppose one question is what format?  Standard
> security_getprocattr
> type hook to just get text is simplest.
> 
> thanks,
> -chris
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
> 



Casey Schaufler
casey at schaufler-ca.com


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs