Klaus Weidner wrote:
On Tue, Oct 03, 2006 at 04:38:48PM -0700, Casey Schaufler wrote:
--- Linda Knippers <[EMAIL PROTECTED]> wrote:
It has a requirement to be able to audit all modifications of the
values of security attributes, so we can audit a bunch of syscalls
that do that (chmod, chown, setxattr, ...). Relabeling files would
definitely count and be covered. There's also a requirement about
auditing changes to the way data is imported/exported, so this is
where the networking stuff comes in. I don't know about domain
transitions.
I think you would have trouble arguing that a domain transition is not
a change in the security state of the system. For the evaluations I
worked auditing was required for any change to uids, gids,
capabilities, sensitivity, integrity, or any other security relevent
attribute.
Yes, it is a change in the process security state.
Domain transitions are auditable already - dynamic transitions through
the auditallow rules on /proc/$PID/attr/*,
Just to be clear - this would catch both dynamic transitions (dyntrans)
and explicitly requested exec transitions. The problem is that the audit
record will record the request for the security state change and not
whether it succeeded.
and automatic transitions by
putting filesystem watches on the *_exec_t binaries you're interested in.
Josh's suggestion of the auditallow will catch all exec transitions
without the false positives I mentioned above. I think the impedance
mismatch between the audit rules and SELinux will make it very hard to
capture SELinux specific actions in an accurate and natural way.
Karl
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
