[redhat-lspp] RBAC Roles

[Daniel J Walsh]

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? 

Dan