[redhat-lspp] RBAC Roles

[Karl MacMillan]

> -----Original Message-----
> From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-
> bounces at redhat.com] On Behalf Of Steve Grubb
> Sent: Tuesday, September 20, 2005 11:25 AM
> To: lspp-list
> Subject: Re: [redhat-lspp] RBAC Roles
> 
> On Tuesday 20 September 2005 09:24, Stephen Smalley wrote:

<snip>

> > And the SELinux policy is the natural point to specify auditing of
> SELinux
> > permission checks.
> 
> I think this is a bad way to do it. When someone asks the admin where did
> this
> message come from, they will have to auditctl -l and grep through policy
> files to figure that out. Also, you can't add a audit rule without
> compiling
> and reloading policy can you? Changing the policy is an auditable event,
> loading the policy is too. This adds 2 event when only 1 was needed. What
> if
> the policy is not on that machine or maybe the policy compiler was removed
> for security?
> 
> > The audit  subsystem was designed to cooperate with/complement the
> security
> > subsystem's native ability to audit object accesses rather than to
> > replace it.
> 
> I don't think we want to replace it. I think we want it to share a lot of
> the
> same kernel infrastructure. The rule gets loaded by auditctl and sent into
> the SE Linux subsystem for evaluation.
> 
> > > The audit system needs to get its hands on this info. We need to be
> able
> > > to write rules like: auditctl -a exit,always -F role=secadm_t
> >
> > Adding improved ability to the audit system to specify context (and
> > context components) on its filters is fine with me, but:
> > - I don't think it obsoletes the use of SELinux's native auditing of its
> > MAC permission checks
> 
> I think the audit system needs to be able to interface with SE Linux code.
> To
> add audit rules, list audit rules, and delete audit rules.
> 
> > - The context and context components need to ultimately be interpreted
> > by SELinux, because the audit subsystem has no direct knowledge of
> > policy components or even the ability to directly look at a security
> > context within the kernel (security fields are opaque outside of the
> > security module).
> 
> Right. I agree. I think auditctl -a exit,always -F role=secadm_t would go
> into
> SE Linux for evaluation. The audit framework does not necessarily need to
> do
> the actual audit event generation. That can come from SE Linux.
> 

Which is semantically the same as changing the policy, it just happens
either in userland tools related to audit or the kernel. If the concern is
simple practicality of not wanting to carry around a policy development
environment, then policy modules combined with a tool to generate special
audit modules would work.

I also think that there is considerable value to keeping the SELinux related
auditing in the SELinux policy. Most importantly, the audit policy can be
analyzed along with the policy. This would allow the considerable investment
in policy analysis tools to be leveraged to continue to be used for audit
analysis.

Karl

------
Karl MacMillan
Tresys Technology
http://www.tresys.com

> > auditctl could certainly pass down the string "role=secadm_r" to the
> > kernel audit subsystem, which could then pass it along to SELinux (via
> > LSM hook), which could encode it into a rule understood by SELinux and
> > returned as a callback to the audit subsystem, and the audit subsystem
> > could later invoke that callback when checking audit filters to allow
> > SELinux to evaluate the rule on the particular opertion.
> 
> Right. This is along the lines of what I'm thinking. Callback would
> probably
> not be necessary. The message will arrive in the filter after
> audit_log_end()
> and we can do any additional filtering there.
> 
> > > What I would like to do is have all the auditing control in the audit
> > > interface so that its easier to teach people in the future. I think it
> > > would be awkward to show them all the auditctl rules and then say oh
> by
> > > the way, if you need to audit a role, you have to go modify the
> policy. I
> > > don't think we want to go down that road.
> >
> > If you want to enable syscall auditing for a given role, then doing so
> > via auditctl is quite reasonable.  But for the SELinux permission check
> > auditing, it really has to be handled by SELinux.
> 
> Agreed. I guess we should work out these details. We need an API. Dustin
> submitted a patch to add label support and I think we need to make some
> changes to the patch. We also need an API to list what's inserted and to
> delete audit rules from SE Linux.
> 
> -Steve
> 
> --
> redhat-lspp mailing list
> redhat-lspp at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-lspp