--- Chris Wright <chrisw(a)osdl.org> wrote:
* Amy Griffis (amy.griffis(a)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(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
Casey Schaufler
casey(a)schaufler-ca.com
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs