[redhat-lspp] RBAC Roles

[Stephen Smalley]

On Wed, 2005-09-21 at 13:03 -0400, Daniel J Walsh wrote:
> So you see auditctl writing new policy modules and then reloading the 
> policy.  So if I as an admin want to watch any process that changes the 
> securitlevel of a file from s0 to something higher or from something 
> higher to s0, the tool will write policy for this?  Seems like the 
> auditctrl will have to understand the policy that is installed on a system.
> 
> How difficult is it to write these rules in auditallow syntax? 

I don't think auditctl should generate policy.  I think we want to
retain the current subdivision of labor between the audit subsystem
(syscall auditing, selectable based on filter rules configurable via
auditctl as well as optionally enabled by other kernel subsystems like
SELinux during syscall processing based on their respective policies)
and the security subsystem (MAC permission check auditing, selectable
based on policy).

I'm ok with the idea of allowing syscall audit filters to be based on
contexts and context components, as long as the interpretation is
handled by SELinux.  That doesn't require regenerating policy.

syscall audit filters let you say things like "Show me all syscalls
performed by sysadm_r processes" or "Show me all calls to open(2) on
files labeled foo_t".  SELinux auditallow rules let you say things like
"Show me all permissions granted to sysadm_r processes" or "Show me all
read and write permission grantings to files labeled foo_t."  And of
course, SELinux audits permission denials by default.

They are controlling different aspects - the occurrences of syscalls
versus MAC permission checks.

-- 
Stephen Smalley
National Security Agency