Problems creating a user

[Armando Aznar]

Hello, i want to do various security tests with selinux.
I have enabled the targeted policy, so all the users run with the user "user_u"
(then all the users have all the permissions in SELinux).
How could i create a user who run with the user "system_u" so this user dont
have all the permissions?
Thanxx in advance

On Mon, 26 Sep 2005 12:31:51 +0200, Armando Aznar said:
>  I have enabled the targeted policy, so all the users run with the
> user
>  "user_u" (then all the users have all the permissions in SELinux). 
>  How could i create a user who run with the user "system_u"
> so this user dont
>  have all the permissions? 
This is probably doomed to failure, because the targeted policy cuts a *lot*
of corners because it's not making any realistic attempt to protect legitimate
system users/types from each other.  You really need to start with the 'strict'
policy - that has support for separating users.

(Basically, in the 'targeted' policy, so many things will treat
'user_u:object_r:unconfined_t' and 'system_u:object_r:unconfined_t' as
being
equivalent that you're not going to get anywhere useful....)

[Stephen Smalley]

On Mon, 2005-09-26 at 13:05 -0400, Valdis.Kletnieks(a)vt.edu wrote:
>  On Mon, 26 Sep 2005 12:31:51 +0200, Armando Aznar said:
>  > I have enabled the targeted policy, so all the users run with the user
>  > "user_u" (then all the users have all the permissions in SELinux).
>  
>  > How could i create a user who run with the user "system_u" so this user
> dont
>  > have all the permissions?
>  
>  This is probably doomed to failure, because the targeted policy cuts a *lot*
>  of corners because it's not making any realistic attempt to protect legitimate
>  system users/types from each other.  You really need to start with the 'strict'
>  policy - that has support for separating users.
>  
>  (Basically, in the 'targeted' policy, so many things will treat
>  'user_u:object_r:unconfined_t' and 'system_u:object_r:unconfined_t' as
> being
>  equivalent that you're not going to get anywhere useful....) 
Just to affirm this point:  Targeted policy is not suitable for user
separation.  Convert to strict policy if you want user separation.

(Side bar: The only reason targeted policy even has multiple user
identities and roles defined is for context compatibility with strict
policy.  If the policy language had a notion of user and role aliases to
parallel the type alias construct, the users and roles would all just be
aliased together for targeted policy.).

-- 
Stephen Smalley
National Security Agency

[Ivan Gyurdiev]

> This is probably doomed to failure, because the targeted policy cuts a
> *lot*
> of corners because it's not making any realistic attempt to protect legitimate
> system users/types from each other.  You really need to start with the 'strict'
> policy - that has support for separating users.
>   
>  
It does not... it has support for separating types of users from other 
types of users...
...and the boundaries between the types are pretty much set in stone at 
this time - you can't
easily change what roles can do - there's staff_r, sysadm_r, secadm_r, 
user_r, system_r,
and that's it.

I wish RBAC would be more flexible...but it isn't (at least not yet).
DAC groups would probably be better for what you're trying to accomplish.

> (Basically, in the 'targeted' policy, so many things will
> treat
> 'user_u:object_r:unconfined_t' and 'system_u:object_r:unconfined_t' as
> being
> equivalent that you're not going to get anywhere useful....)
>   
>  
They're equivalent in strict policy as well. The user field of the 
SELinux context is not really used at this time.

[Stephen Smalley]

On Mon, 2005-09-26 at 13:28 -0400, Ivan Gyurdiev wrote:
>  It does not... it has support for separating types of users from
> other 
>  types of users... 
That is user separation, just not per-Linux user separation.
  
>  ...and the boundaries between the types are pretty much set in stone
> at 
>  this time - you can't
>  easily change what roles can do - there's staff_r, sysadm_r, secadm_r, 
>  user_r, system_r,
>  and that's it. 
...unless you modify policy sources.

>  I wish RBAC would be more flexible...but it isn't (at least not
> yet).
>  DAC groups would probably be better for what you're trying to accomplish. 
Depends on what he wants to accomplish.  DAC cannot truly isolate users
in any mandatory sense.  

>  >(Basically, in the 'targeted' policy, so many things will
> treat
>  >'user_u:object_r:unconfined_t' and 'system_u:object_r:unconfined_t'
> as being
>  >equivalent that you're not going to get anywhere useful....)
>  >  
>  >
>  They're equivalent in strict policy as well. The user field of the 
>  SELinux context is not really used at this time. 
The particular example might not be good, but the user identity does
come into play in strict policy in bounding the set of roles (and thus
the set of domains).

-- 
Stephen Smalley
National Security Agency

[Ivan Gyurdiev]

> >...and the boundaries between the types are pretty much set in
> stone at 
> >this time - you can't
> >easily change what roles can do - there's staff_r, sysadm_r, secadm_r, 
> >user_r, system_r,
> >and that's it.
> >    
> >
>
> ...unless you modify policy sources.
>   
>  
You're right. The problem isn't that RBAC isn't flexible - it's
_too_ 
flexible. I think it would be confusing to admins to write policy. Maybe 
if we could create some sort of friendly app with the most-common macros 
an admin could want to use, and their descriptions...  I guess we're 
moving in the right direction with those management apis...hmm