[redhat-lspp] RBAC Roles

[Stephen Smalley]

On Fri, 2005-09-23 at 17:04 -0400, Steve Grubb wrote:
> On Friday 23 September 2005 16:33, Stephen Smalley wrote:
> > To clarify, I think we need to focus on making incremental improvements
> > to what exists to meet the actual requirements, not completely
> > overhauling what exists to meet wishlist features.
> 
> What wishlist? If you are referring to the "auditing under lspp" mail, lets 
> discuss those under that thread.

In the prior message in this thread, you said we need to do 3 things and
listed them.  That is what triggered my reply (and I quoted your text
above my reply there).

> I don't think anyone ever suggested moving the functionality. Out of 
> curiosity, what is the basis of your objection to allowing auditing via the 
> audit system?

The audit system was designed to complement SELinux (or other LSMs), not
to completely supersede their ability to emit object-based access check
audit records.  It has a fairly nice approach, with syscall-level
auditing handled entirely by the audit system since SELinux/LSMs cannot
(and should not) provide that functionality and an interface to allow
SELinux (or other LSMs) to emit object-based access check audit records
and to trigger syscall-level auditing for the higher level operation
when emitting such records.  Clean subdivision of labor with
well-defined responsibilities for each subsystem.

Yes, this means that in the mechanism, the "audit policy" is
partitioned.  That is ok.  One can certainly centralize the front-end
and allow the toolchain to split out the parts.
  
> This is not in the requirements. The question I posed on the "auditing under 
> lspp" thread is whether or not this capability should exist. No one has 
> commented either way on the list I posted.

Adding context and possibly context component filters to the syscall
audit filters is fine with me, as long as SELinux does the
interpretation of the component filters.  That is separate from the
issue of dealing with auditing of MAC checks.  But I do think that it
should be done incrementally, i.e. first get contexts into the audit
records via Dan/Dustin's patch, then allow complete context-based
filters that can be directly interpreted by the audit system, then
optionally allow context component-based filters as a "nice to have"
feature as time permits. 

> Binary policy regeneration means the audit rules are persistent. That's way 
> more invasive than what I was looking at.

What is the more common case - non-persistent or persistent audit rules?
Keeping in mind that if I set up an audit filter today that I only want
around for 3 hours and my machine spontaneously reboots after an hour,
I'd still prefer to have that audit filter revived automatically.  

In any event, one can mutate policy images in memory and drop them into
the kernel without necessarily modifying a file on disk.  That is what
is presently done for booleans and local user definitions, but we are
trying to move away from it.

> The only ones that are called out in the specs are context labels, roles, and 
> net addresses. Everything else in my list is up for debate.

-- 
Stephen Smalley
National Security Agency