[redhat-lspp] RBAC Roles

[Stephen Smalley]

On Mon, 2005-09-26 at 12:18 -0400, schaufler-ca.com - Casey Schaufler
wrote:
> Real world audit useage (based on about 15 years
> experiance with Solaris, Irix, and the POSIX 1003.1e/2c
> group) is much like aircraft operation: Long periods
> of boredom punctuated by minutes of sheer terror.
> Usually the rules don't get changed much. When an
> event occurs that audit is truely useful for the
> parameters start getting adjusted like mad, as
> the filters are tweeked and refined to track down
> miscreants. This is the case where reloading the
> whole policy is a problem. Often when you want a
> change you want it NOW, and the information you
> get is likely to result in another change that you
> want NOW.  Further, you often zero in on a particular
> user or even a process. It seems that there might
> be something amiss if you have to reload the entire
> system security policy just to increase the auditing
> on a particular process.  Well, that's my view, and
> that and $2.65 will get you a Starbucks.

$1.58 works for me here for a tall regular coffee.  In any event:
- The syscall audit filters can be configured via auditctl without
touching SELinux policy at all.  That kind of filter is what you want
for zeroing in on a particular user (based on uid) or process (based on
pid).
- SELinux audit rules in its policy are only about auditing MAC
permission checks (grantings or denials) based on the same inputs as the
permission check itself, i.e. the relevant security contexts and
permissions being checked.  They look just like allow rules except for
the keyword; auditallow rules enable auditing of granted permissions
(e.g. audit all granted load_policy permissions), and dontaudit rules
disable auditing of denied permissions (e.g. don't audit denied attempts
to access some file that every program tries to do during startup due to
a library constructor).

I'm not sure whether the latter falls into the class of auditing that
you describe above as requiring rapid and highly dynamic adjustment.

Also, reloading policy isn't _that_ expensive.  Rewriting a binary
policy file might be.  Looks like iptables operates by grabbing the
entire config from the kernel, then mutating it in memory for the
specified rules, then dropping the new config into the kernel.  That
would be feasible for policy as well, although we have been looking to
migrate away from such direct manipulations and toward pushing all
changes through the toolchain and generating a policy file on each
changeset.

-- 
Stephen Smalley
National Security Agency