From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Tue, 23 Sep 2008 10:44:32 -0400 Subject: [refpolicy] (u|r)bacsep: initial testing In-Reply-To: <1216224735.21191.50.camel@gorn> References: <1216224735.21191.50.camel@gorn> Message-ID: <1222181072.4240.1.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 really needs to be tested by people whose projects depend on proper role separations. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150