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

[Stephen Smalley]

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.

> 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.

-- 
Stephen Smalley
National Security Agency