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

[Stephen Smalley]

On Tue, 2005-11-29 at 07:55 -0600, George Wilson wrote:
> Audit by role is still an issue.
> Filter in userspace?
> Steve: No. Could jam netlink connection.
> Need to look at the policy compiler.
> SELinux is based on SIDs.
> Have compiler look at roles and types to compose SIDs from bit fields
> rather than sequence.
> SELinux comparisons wouldn't have to change; just policy.
> George: Wouldn't that severely restrict the number of possible roles,
> etc. given 32-bit SIDs?
> Steve: Yes. But can have variable size bitfields to encode data.
> George: I thought a hash table might be an option.
> Still thinking through but that's one possible approach.
> Need to discuss on list.

Not sure where this idea originated, but changing SIDs is neither
necessary nor desirable for audit by role.  For audit by role, auditctl
composes a filter rule that includes the role string, and passes that to
the kernel audit system.  The kernel audit system can then do one of two
things:
1) pass the filter rule to SELinux to compile to an internal form (this
_may_ include conversion to an integer id value for the role, but that
isn't the same as the SID), and later call SELinux when the filter rule
needs to be evaluated, or
2) retain the rule with the role still in string form, and only use
SELinux to split security contexts into components as needed to compare
the strings.

Note that the kernel audit system is already collecting the relevant
security context strings (both for the task and for any inodes
accessed), so it already has that information; no point converting to
SIDs for comparison purposes.  The latter approach is very simple and
avoids any need for changes to SELinux other than exporting an interface
for splitting a context string; everything else can be done in the audit
code directly.

> George: Klaus had concerns about role composition.
> Dan: To compose w/dominance relation, need to write policy.
> Already have tools to extract role data for a user.
> George: May have an issue with roles composition.
> Could SELinux user == role?
> Dan: Place on list and get an opinion.

Using the SELinux user as RBAC role may be reasonable (particularly with
seusers mapping Linux users to SELinux users as "role sets" these days),
but doesn't address the issue of role hierarchies et al.  role dominance
at least lets you establish relationships among SELinux roles; there is
not equivalent for SELinux users.  But it isn't clear that such
relationships need to be in the kernel policy itself; you could always
define them at a higher level and then generate the lower level policy
accordingly.

> Need to analyze NSA SELinux tescases and rebase to reference policy if
> necessary.
> Should be the same but may not.
> Joy to look at.
> Red Hat QA is running LTP version of SELinux testcases.

The obvious major issue with the testsuite is that the testsuite policy.
The two problem areas will be:
a) testsuite policy is currently copied into the policy source tree
followed by a make load, so it needs to be converted to build a policy
module instead and install it via semodule,
b) testsuite policy makes direct references to some types in the "base"
policy of the system, whereas reference policy wants all such references
to be encapsulated via the interfaces (macros) of the reference policy.

-- 
Stephen Smalley
National Security Agency