[redhat-lspp] RBAC Roles

[Karl MacMillan]

> -----Original Message-----
> From: Daniel J Walsh [mailto:dwalsh at redhat.com]
> Sent: Wednesday, September 21, 2005 1:03 PM
> To: Karl MacMillan
> Cc: 'Steve Grubb'; 'lspp-list'
> Subject: Re: [redhat-lspp] RBAC Roles
> 
> Karl MacMillan wrote:
> 
> >>-----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
> >
> >
> >
> 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?
> 

Not exactly certain what you are asking. This is an interesting example for
auditing, though. It seems like this rule is hard to express in general (I
feel compelled to point out that upgrading is probably not an interesting
event). SELinux best case is (I think):

auditallow mlsfiledowngrade file_type : file relabelto;

Obviously a) this will audit all downgrades not just for a specific level,
b) it requires an understanding of the policy. How would this be solved with
only the audit system? It seems like selinux object classes and permissions
are better able to express what you want to audit.

As far as generating policy goes, no one has really worked on
programmatically generating modules, but I think that it would be fairly
straightforward with a lot of practical pains. For example, would there be a
special audit module that would constantly be modified by the audit tool?

Karl


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

> Dan