[redhat-lspp] LSPP Development Telecon 11/16/2005 Minutes

[Daniel J Walsh]

Stephen Smalley wrote:
> On Fri, 2005-11-18 at 00:34 -0600, Debora Velarde wrote:
>   
>> --------------------
>> RBAC - audit by role
>> --------------------
>> - auditing by roles in order to meet RBAC
>> - pretty good size task, going to take some time to do
>> - filtering by strings vs bitmasks?
>> - controls inside selinux?
>> - so far no real solution
>> - task is open for someone to start looking into
>> - whoever wants to jump into that however they want
>> - George thinks Stephen had objections to adding controls
>> - If you want to suppress records early on would need controls in there
>>     
>
> Sorry I wasn't able to attend - had a conflicting meeting, and won't be
> around next week.  To clarify my position here:  I have no problem with
> the kernel audit system and auditctl supporting syscall audit filters
> (or watches) based on roles, other components of security contexts, or
> entire security contexts.  The only delicate issue is splitting up
> responsibility between the kernel audit system and SELinux for the
> interpretation and testing of such audit filters so that we don't
> hardcode knowledge of the security context format in the audit system.
> My earlier objection was to having auditctl / the kernel audit system
> directly configure the SELinux auditallow/dontaudit/auditdeny rules in
> the kernel, which I still think would be a mistake, versus having some
> audit frontend tool that regenerates SELinux audit-related rules and
> builds a policy module from them for a policy reload.
>
>   
>> Understanding what RBAC means by a role and what we mean by a role
>> - selinux has roles
>> - are we meeting RBAC requirement to the right thing?
>> - selinux roles are a bit lower level
>>     
>
> Perhaps, but they can certainly represent RBAC roles.  Note also that
> with the seusers mapping, we are effectively now using SELinux user
> identities as "role sets" and mapping Linux users to these "role sets",
> so one might treat a SELinux user identity as a RBAC role if you needed
> a larger grouping.
>
>   
>> sys_admin restarting system service
>> - need to make sure not actually switching roles unless you do a new role
>>     
>
> Older SELinux required explicit operations for all such role changes,
> including use of run_init for restarting services in the proper context,
> but that was viewed as unacceptable for users in Fedora/RHEL, so
> automatic role transitions were applied there.
>   
But this was removed before we had targeted policy so this might/should 
be something we replace in MLS policy.
dnl define(`direct_sysadm_daemon') I disabled in not defined in MLS policy.

>   
>> Big task partially because of politics
>> - How are you going to do that, by policy?
>> - could change to a hash for faster compare, already doing that for files
>> - Stephen Smalley doesn't want capability of inserting anything into 
>> selinux w/o going through policy
>> - other LSMs might want to use audit
>> - don't want to closely tangle audit with selinux
>> - RBAC is closely tied to selinux
>> - do we need an immutable role id, like login_uid
>> - we just need to know what role caused it, selinux role should be doable 
>> that way
>> - don't want a new set of hooks to do enforcement
>> - selinux role doesn't match what RBAC considers a role
>>     
>
> See my comments above.  Separate role id would be a mistake; just one
> more attribute that can potentially become inconsistent, has no
> well-defined control semantics, and is completely unknown to existing
> kernel APIs and userspace.
>
>   


--