From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 09 Mar 2010 08:58:21 -0500
Subject: [refpolicy] user vs unconfined
In-Reply-To: <201003091314.03493.russell@coker.com.au>
References: <201003091314.03493.russell@coker.com.au>
Message-ID: <1268143101.4155.117.camel@gorn.columbia.tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Tue, 2010-03-09 at 13:14 +1100, Russell Coker wrote:
> Why do unconfined_t and user_t use the same file types for almost everything 
> in the latest policy?

Its been like this since the Dec 10 2008 release.

Since all of the derived types encoded the role into the type, eg
user_home_t vs staff_home_t, the original idea was to use the role to do
the separating, via constraints.  Then the duplicated TE rules would
fall out, because everything would merged into user_home_t, ssh_home_t,
mozilla_t, etc.

Unfortunately, the RBAC isn't complete, so role transitions wouldn't
work on directories (i.e. it requires a kernel change).  So as a second
best thing, we went with seuser based separation.  UBAC is not exactly
the same separation as RBAC, but its close enough; also it has the nice
benefit of making it trivial to add new separations, since seusers can
be added to the policy through semanage, with no effort.

I'd certainly like to get the RBAC implemented in the kernel, so we can
get the exact role separation back.  But it hasn't happened yet.

You can find the discussion on all of this by searching the NSA SELinux
list archives for "rbacsep" and "(u|r)bacsep" in the subject.

> This means that if an unconfined user has bad Unix permissions on their home 
> directory then user_t can replace a file that will be executed and therefore 
> gain unconfined_t access.
> 
> So is there any benefit in using user_t in such a scheme?  If there isn't a 
> benefit, and as almost all users of the Fedora policy will only use 
> unconfined_t for user sessions

Dan turned off UBAC in Fedora.  Before we implemented UBAC, he was
already merging the derived types.

>  it seems that the thing to do would be to 
> restore the previous separation of user_t, staff_t, sysadm_t, and 
> unconfined_t for those who need it as it won't actually affect the Fedora 
> users.
> 
> Or of course I could just maintain a private fork of the policy for Debian.
> 
> Since 2002 the Debian policy has denied root:user_r:user_t the ability to take 
> over the system and I plan to keep it that way.

Sounds like a play machine configuration.  That is still possible as
long as the real root home dir is root2:object_r:user_home_dir_t or some
other seuser.

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