[refpolicy] user vs unconfined

[refpolicy] user vs unconfined

[Russell Coker]

Why do unconfined_t and user_t use the same file types for almost everything 
in the latest policy?

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

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

[refpolicy] user vs unconfined

[Justin P. mattock]

On 03/08/2010 06:14 PM, Russell Coker wrote:
> Why do unconfined_t and user_t use the same file types for almost everything
> in the latest policy?
>
> 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 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.
>


doesn't matter to me(although my opinion probably doesn't matter).
let me know I can load up the latest policy and see.

Justin P. Mattock

[refpolicy] user vs unconfined

[Michal Svoboda]

Russell Coker wrote:
> 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.

Shouldn't this be prevented by the UBAC constrains? (ie. the user part
of the context matters.)

> Or of course I could just maintain a private fork of the policy for Debian.

Not a good idea.

Michal Svoboda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100309/fd9f2750/attachment.bin 

[refpolicy] user vs unconfined

[Christopher J. PeBenito]

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

[refpolicy] user vs unconfined

[Russell Coker]

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

[refpolicy] user vs unconfined

[Christopher J. PeBenito]

On Tue, 2010-03-23 at 13:16 +1100, Russell Coker wrote:
> 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?

No particular reason.  No one has gotten around to it.

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

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

I think the correct thing to do in procmail's case is to make a
maildir_t or the like.  Then procmail can only write to the maildir, if
its in the user's home directory.

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