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....)
On Mon, 2005-09-26 at 13:05 -0400, Valdis.Kletnieks@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.).
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.
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).
...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
selinux@lists.fedoraproject.org
-
Armando Aznar -
Ivan Gyurdiev -
Stephen Smalley -
Valdis.Kletnieks＠vt.edu