I'm using the latest fedora strict policy sources, and have noticed that the generated policy.conf file is lacking generated policy entries for extra users.
I added myself to the users file:
# sample for regular user user jmorris roles { user_r };
compiled policy:
# make policy.conf
But the only entry related to the user is the one I added in the users file:
# grep jmorris policy.conf user jmorris roles { user_r };
Have I missed a step or is something wrong in the policy compilation process?
- James
On Thu, 2004-10-14 at 10:43, James Morris wrote:
# grep jmorris policy.conf user jmorris roles { user_r };
Did you mean to do: grep '^user' policy.conf
For me, with selinux-policy-strict-sources-1.17.3-1, that shows system_u, user_u, root, cyrus and any manually added users.
On Thu, 2004-10-14 at 10:43 -0400, James Morris wrote:
But the only entry related to the user is the one I added in the users file:
# grep jmorris policy.conf user jmorris roles { user_r };
Have I missed a step or is something wrong in the policy compilation process?
It's been that way as long as I can remember; you also need to do: full_user_role(jmorris)
On Thu, 2004-10-14 at 11:06, Colin Walters wrote:
It's been that way as long as I can remember; you also need to do: full_user_role(jmorris)
That would define a separate role/domain for jmorris. Is that what he wants?
On Thu, 14 Oct 2004, Stephen Smalley wrote:
On Thu, 2004-10-14 at 11:06, Colin Walters wrote:
It's been that way as long as I can remember; you also need to do: full_user_role(jmorris)
That would define a separate role/domain for jmorris. Is that what he wants?
Yes.
- James
On Thu, 14 Oct 2004, Colin Walters wrote:
It's been that way as long as I can remember; you also need to do: full_user_role(jmorris)
Thanks, that worked, but I can't recall doing it before.
- James
On Thu, 2004-10-14 at 11:13, James Morris wrote:
On Thu, 14 Oct 2004, Colin Walters wrote:
It's been that way as long as I can remember; you also need to do: full_user_role(jmorris)
Thanks, that worked, but I can't recall doing it before.
That only makes sense if you are going to do: user jmorris roles jmorris_r; role jmorris_r types jmorris_t;
Otherwise, full_user_role(jmorris) is just going to define some types and rules that aren't ever going to be useable.
But why do you want a per-user role/domain?
On Thu, 2004-10-14 at 11:15, Stephen Smalley wrote:
That only makes sense if you are going to do: user jmorris roles jmorris_r; role jmorris_r types jmorris_t;
Also, if you want to be able to transition from user_r to this role, e.g. via newrole or su, you likely need: role_tty_type_change(user,jmorris)
On Thu, 14 Oct 2004, Stephen Smalley wrote:
On Thu, 2004-10-14 at 11:13, James Morris wrote:
On Thu, 14 Oct 2004, Colin Walters wrote:
It's been that way as long as I can remember; you also need to do: full_user_role(jmorris)
Thanks, that worked, but I can't recall doing it before.
That only makes sense if you are going to do: user jmorris roles jmorris_r; role jmorris_r types jmorris_t;
Otherwise, full_user_role(jmorris) is just going to define some types and rules that aren't ever going to be useable.
But why do you want a per-user role/domain?
I don't know, I just wanted to restore what I thought was normal behavior.
So even in strict policy now, all normal users are user_u:user_r:user_t ?
- James
On Thu, 2004-10-14 at 12:02, James Morris wrote:
I don't know, I just wanted to restore what I thought was normal behavior.
Separate roles per user were never part of the example policy. It is true that common practice prior to and outside of the Fedora SELinux implementation is to at least maintain separate entries in policy/users for users authorized for staff_r and sysadm_r, and optionally to maintain separate entries for users authorized for user_r to provide stronger user accountability even though they had the same permissions.
So even in strict policy now, all normal users are user_u:user_r:user_t ?
That's the default. You can disable user_canbe_sysadm and explicitly authorize users for staff_r/sysadm_r/system_r for better security. Then, user_r users cannot use su/sudo/userhelper to gain privileges, and access to sysadm_r is entirely governed by policy. That doesn't require creating separate roles per user. But the lack of integration of existing user databases and tools with the SELinux users database makes it difficult to disable user_canbe_sysadm by default.
selinux@lists.fedoraproject.org
-
Colin Walters -
James Morris -
Stephen Smalley