From: russell@coker.com.au (Russell Coker)
Date: Tue, 23 Mar 2010 13:16:12 +1100
Subject: [refpolicy] user vs unconfined
In-Reply-To: <1268143101.4155.117.camel@gorn.columbia.tresys.com>
References: <201003091314.03493.russell@coker.com.au>
	<1268143101.4155.117.camel@gorn.columbia.tresys.com>
Message-ID: <201003231316.13176.russell@coker.com.au>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Wed, 10 Mar 2010, "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
> 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).

Why hasn't the kernel change been implemented?  I know it would be a moderate 
amount of work to get role transitions on creation under /tmp and role 
comparisons with absolute role names (as well as the current role dominance).  
But surely this sort of thing was always the plan.

My suggestion of removing ":object_r" from file contexts as an optimisation 
for storage space (and sometimes performance) was rejected for a reason.

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

I've read that, thanks for the reference.

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

Fedora 12 now has a admin_home_t.  So it seems that admin_home_t has just 
replaced sysadm_home_t and unconfined_home_t.

Something like admin_home_t is necessary to stop system processes that access 
home directories (such as procmail) from messing with files under /root.  
Said daemons will be running with system_u and thus not be restricted with 
ubac.

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

OK, I'll give that a go.  Thanks.

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog