[redhat-lspp] RBAC Roles

[Stephen Smalley]

On Fri, 2005-09-23 at 13:08 -0400, Stephen Smalley wrote:
> On Fri, 2005-09-23 at 06:26 -0400, Steve Grubb wrote:
> > I think we need to do 3 things: 1) have auditctl convert from human readable 
> > to the binary internal format for SE Linux, 2) from kernel/audit.c call a 
> > hook inside security/selinux/ to a new function that takes the 1 line audit 
> > rule and places it in the right place without reloading policy (this is only 
> > to generate or suppress messages based on subject or object labels or roles) 
> > 3) create an interface where SE Linux passes arguments instead of text to the 
> > audit system for further filtering. The audit system then calls 
> > log_start/log_format/log_end to generate the message.
> > 
> > The audit system cannot touch MAC rules at all. Just the messaging that may 
> > result from the evaluation of access requests. This is required to meet both 
> > RBAC and LSPP. 
> 
> Hi,
> 
> I think that this is not only not "required", but unreasonable in the
> time frame in which we are working.

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.  I further disagree
with moving the auditallow/dontaudit functionality from SELinux policy
into auditctl and the audit subsystem.  

I can agree with:
- enhancing auditctl and kernel audit subsystem to allow syscall audit
filters based on entire security contexts (trivial, given Dan/Dustin's
patches for obtaining such contexts),
- enhancing SELinux policy to support auditallow/dontaudit rules based
on levels (if that is truly required; need to look further at the actual
requirement and whether we can't do this based on type as I'm not sure
why anyone would be suppressing auditing entirely on _all_ objects with
a given level - seems like the wrong granularity),
- creating new utilities and front-ends to enable easier configuration
of SELinux audit rules without requiring policy sources and making the
binary policy regeneration and reload transparent to the user,
- only allowing such regeneration and reload to a dedicated domain for a
particular utility and/or daemon through which all such changes are
made.

I can also see the desirability of allowing syscall audit filters based
on context components (e.g. role, type, level), but I'm not entirely
convinced it is truly _required_ (versus entire contexts), and it will
be more invasive to support, including an interface between the audit
subsystem and SELinux for building and evaluating such audit filters. I
view that as more wishlist material.

-- 
Stephen Smalley
National Security Agency