From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Thu, 16 Oct 2008 15:01:13 -0400
Subject: [refpolicy] (u|r)bacsep: initial testing
In-Reply-To: <1216224735.21191.50.camel@gorn>
References: <1216224735.21191.50.camel@gorn>
Message-ID: <1224183673.21012.64.camel@gorn.columbia.tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Wed, 2008-07-16 at 12:12 -0400, Christopher J. PeBenito wrote:
> For those that are interested, the SELinux user-based separation policy
> is ready for some initial testing.  It can be checked out from the
> rbacsep branch of the refpolicy SVN repo.  Not all of the type aliases
> are in place for compatibility yet, so switching from an existing policy
> should be done in permissive.
> 
> A question that comes up is how exactly to to determine which types
> should be constrained by ubac.  The obvious answer would seem to be that
> if the user isn't system_u, then there should be ubac constraints on the
> access check.  But the problem is that creating new files gets your
> selinux user on files.  So if you look in /etc, you're likely to see non
> system_u files, such as ld.so.cache.  The problem is that we don't want
> ubac constraints on these files.  In addition, since there is no
> run_init on redhat (and possibly other distros) machines, restarted
> services would get non system_u users, which would also cause problems.
> 
> My current implementation is actually more of an allow by default setup,
> where types are explicitly marked as being ubac constrained.  Obviously
> deny by default would be preferred, but that would require all exempted
> types to be marked instead.  The problem is the number of exempted types
> far outnumbers the constrained types.  I'm open to suggestions on
> tweaking this design, especially if it gets us a deny by default without
> the pain of marking most types in the policy as exempted.

ping

This is the last call.  I have not heard any comments from the
community.  User-based separations have finished going through vetting
interally at Tresys; I plan to finalize this and then merge it into
trunk in the next week or so unless there are any objections raised.

This really needs to be tested by people whose projects depend on proper
role separations.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150