Contrast the following two:
% su -c id Password: uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:sysadm_r:sysadm_t
% sudo id Password: uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:user_r:user_t
How do I change my local policy so have sudo grant the same sysadm permissions as su does? Is it possible to make it tunable? Or is this something that is very dangerous and should not be done? Thanks!
On Thu, 2004-03-11 at 10:19, Aleksey Nogin wrote:
Contrast the following two:
% su -c id Password: uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:sysadm_r:sysadm_t
% sudo id Password: uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:user_r:user_t
How do I change my local policy so have sudo grant the same sysadm permissions as su does? Is it possible to make it tunable? Or is this something that is very dangerous and should not be done? Thanks!
sudo authenticates the current user, not the target user, so having it change the SELinux user identity would be dangerous. It can change roles (if the current user identity is authorized for the role) via the -r option. Hence, if you add yourself to policy/users and authorize yourself for staff_r and sysadm_r and reload your policy, then you should be able to do sudo -r sysadm_r <command>.
In order to have sudo safely change the SELinux user identity (to root), you would need another mechanism for specifying what roles/domains are permitted to the calling user, e.g. new fields in /etc/sudoers. Even then, you still need to start from staff_r in order to reach sysadm_r; the policy doesn't allow user_r to transition to sysadm_r (if SELinux is in enforcing mode).
Stephen Smalley wrote:
On Thu, 2004-03-11 at 10:19, Aleksey Nogin wrote:
Contrast the following two:
% su -c id Password: uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:sysadm_r:sysadm_t
% sudo id Password: uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:user_r:user_t
How do I change my local policy so have sudo grant the same sysadm permissions as su does? Is it possible to make it tunable? Or is this something that is very dangerous and should not be done? Thanks!
sudo authenticates the current user, not the target user, so having it change the SELinux user identity would be dangerous. It can change roles (if the current user identity is authorized for the role) via the -r option. Hence, if you add yourself to policy/users and authorize yourself for staff_r and sysadm_r and reload your policy, then you should be able to do sudo -r sysadm_r <command>.
In order to have sudo safely change the SELinux user identity (to root), you would need another mechanism for specifying what roles/domains are permitted to the calling user, e.g. new fields in /etc/sudoers. Even then, you still need to start from staff_r in order to reach sysadm_r; the policy doesn't allow user_r to transition to sysadm_r (if SELinux is in enforcing mode).
All true.
But there's always sudo su -
73 de Jeff
On Thu, 2004-03-11 at 16:17, Jeff Johnson wrote:
All true.
But there's always sudo su -
With SELinux in enforcing mode, that would still require root password authentication; pam_rootok performs a SELinux permission check (in addition to the usual test) to see whether the calling domain is authorized to bypass normal authentication. And the role and domain transitions would still need to be authorized; if you started from user_r, SELinux wouldn't let you get to sysadm_r (unless someone has messed up the policy).
Is there documentation on SELinux other than the various papers, HOWTOs, and FAQs? In particular, is anyone specifically working on the guidance documents listed on the to do page at the NSA site?
Doug Nicholson djnichol@scc.net
On 11.03.2004 07:36, Stephen Smalley wrote:
sudo authenticates the current user, not the target user,
Well, sudo + sudoers does authenticate the "I am somebody who can act on behalf of the target user", why is this insufficient?
so having it change the SELinux user identity would be dangerous.
Even if explicitly permitted by sudoers?
It can change roles (if the current user identity is authorized for the role) via the -r option. Hence, if you add yourself to policy/users and authorize yourself for staff_r and sysadm_r and reload your policy, then you should be able to do sudo -r sysadm_r <command>.
Do you expect everybody who are used to doing things via sudo (a lot of places where more than one user has admin access have policies insisting on sudo - in particular because sudo will log everything) to be willing to figure this out? Why is this information (e.g. "user x is allowed to act as root when re-authenticated") has to be listed in _two_ separate places (sudoers and policies)?
In order to have sudo safely change the SELinux user identity (to root), you would need another mechanism for specifying what roles/domains are permitted to the calling user, e.g. new fields in /etc/sudoers.
That would be the best solution IMHO. Should I file a Bugzilla RFE?
Even then, you still need to start from staff_r in order to reach sysadm_r; the policy doesn't allow user_r to transition to sysadm_r (if SELinux is in enforcing mode).
Not sure I understand what you are saying - it works with su, why can't it be made to work with sudo?
----
On 11.03.2004 13:17, Jeff Johnson wrote:
All true.
But there's always sudo su -
I wish it was that easy...
audit(1079073344.898:0): avc: denied { execute } for pid=20828 exe=/usr/bin/sudo name=su dev=hda2 ino=3662894 scontext=user_u:user_r:sudo_t tcontext=system_u:object_r:su_exec_t tclass=file audit(1079073344.898:0): avc: denied { entrypoint } for pid=20828 exe=/usr/bin/sudo path=/bin/su dev=hda2 ino=3662894 scontext=user_u:user_r:user_t tcontext=system_u:object_r:su_exec_t tclass=file audit(1079073344.898:0): avc: denied { read } for pid=20828 exe=/usr/bin/sudo path=/bin/su dev=hda2 ino=3662894 scontext=user_u:user_r:sudo_t tcontext=system_u:object_r:su_exec_t tclass=file audit(1079073344.930:0): avc: denied { search } for pid=20828 exe=/bin/su dev= ino=791 scontext=user_u:user_r:user_t tcontext=system_u:object_r:security_t tclass=dir audit(1079073344.930:0): avc: denied { read write } for pid=20828 exe=/bin/su name=access dev= ino=6 scontext=user_u:user_r:user_t tcontext=system_u:object_r:security_t tclass=file audit(1079073344.930:0): avc: denied { compute_av } for pid=20828 exe=/bin/su scontext=user_u:user_r:user_t tcontext=system_u:object_r:security_t tclass=security audit(1079073344.935:0): avc: denied { read } for pid=20828 exe=/bin/su name=shadow dev=hda2 ino=229911 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shadow_t tclass=file audit(1079073344.935:0): avc: denied { getattr } for pid=20828 exe=/bin/su path=/etc/shadow dev=hda2 ino=229911 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shadow_t tclass=file audit(1079073345.026:0): avc: denied { compute_user } for pid=20828 exe=/bin/su scontext=user_u:user_r:user_t tcontext=system_u:object_r:security_t tclass=security audit(1079073345.079:0): avc: denied { check_context } for pid=20828 exe=/bin/su scontext=user_u:user_r:user_t tcontext=system_u:object_r:security_t tclass=security audit(1079073345.080:0): avc: denied { compute_relabel } for pid=20828 exe=/bin/su scontext=user_u:user_r:user_t tcontext=system_u:object_r:security_t tclass=security audit(1079073345.080:0): avc: denied { relabelfrom } for pid=20828 exe=/bin/su name=7 dev= ino=9 scontext=user_u:user_r:user_t tcontext=user_u:object_r:user_devpts_t tclass=chr_file audit(1079073345.080:0): avc: denied { relabelto } for pid=20828 exe=/bin/su name=7 dev= ino=9 scontext=user_u:user_r:user_t tcontext=root:object_r:sysadm_devpts_t tclass=chr_file audit(1079073345.080:0): avc: denied { write } for pid=20828 exe=/bin/su name=exec dev= ino=1364983829 scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=file audit(1079073345.080:0): avc: denied { setexec } for pid=20828 exe=/bin/su scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=process audit(1079073345.082:0): avc: denied { setuid } for pid=20829 exe=/bin/su capability=7 scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=capability audit(1079073345.083:0): avc: denied { transition } for pid=20829 exe=/bin/su path=/bin/bash dev=hda2 ino=3662881 scontext=user_u:user_r:user_t tcontext=root:sysadm_r:sysadm_t tclass=process audit(1079073345.083:0): avc: denied { siginh } for pid=20829 exe=/bin/bash scontext=user_u:user_r:user_t tcontext=root:sysadm_r:sysadm_t tclass=process audit(1079073345.084:0): avc: denied { rlimitinh } for pid=20829 exe=/bin/bash scontext=user_u:user_r:user_t tcontext=root:sysadm_r:sysadm_t tclass=process audit(1079073345.084:0): avc: denied { noatsecure } for pid=20829 exe=/bin/bash scontext=user_u:user_r:user_t tcontext=root:sysadm_r:sysadm_t tclass=process
On Fri, 12 Mar 2004 17:39, Aleksey Nogin aleksey@nogin.org wrote:
In order to have sudo safely change the SELinux user identity (to root), you would need another mechanism for specifying what roles/domains are permitted to the calling user, e.g. new fields in /etc/sudoers.
That would be the best solution IMHO. Should I file a Bugzilla RFE?
Good idea. If you would like to contribute some code then that would be appreciated, the people doing SE Linux coding are all fairly busy at the moment...
But there's always sudo su -
I wish it was that easy...
audit(1079073344.898:0): avc: denied { execute } for pid=20828 exe=/usr/bin/sudo name=su dev=hda2 ino=3662894 scontext=user_u:user_r:sudo_t tcontext=system_u:object_r:su_exec_t tclass=file audit(1079073344.898:0): avc: denied { entrypoint } for pid=20828 exe=/usr/bin/sudo path=/bin/su dev=hda2 ino=3662894 scontext=user_u:user_r:user_t tcontext=system_u:object_r:su_exec_t tclass=file
sudo_t transitions to another domain upon executing shell_exec_t. If you execute a binary that's not of type shell_exec_t then that doesn't work.
The following may work: sudo sh -c su -
On 13.03.2004 21:15, Russell Coker wrote:
sudo_t transitions to another domain upon executing shell_exec_t. If you execute a binary that's not of type shell_exec_t then that doesn't work.
Is there a reason for that? This is kind of unfortunatye - one of the big advantages of sudo is that it logs everything and having to execute the shell first is kind of inconvenient. Can transition on an ordinary bin_t be added?
Aleksey Nogin wrote:
On 13.03.2004 21:15, Russell Coker wrote:
sudo_t transitions to another domain upon executing shell_exec_t. If you execute a binary that's not of type shell_exec_t then that doesn't work.
Is there a reason for that? This is kind of unfortunatye - one of the big advantages of sudo is that it logs everything and having to execute the shell first is kind of inconvenient. Can transition on an ordinary bin_t be added?
I have just modified sudo to exec $SHELL -c COMMAND when in SELinux mode.
This should cause the transitions to happen properly. SELinux will start the default shell under the context of the user, or the context overridden by the -r qualifier. Then if the user specified a command with context, the transition should happen.
so if the user specified
sudo -r sysadm_r rpm -Uhv bind-9.2.3-9.i386.rpm
rpm should end up running in rpm_t context, Just as if you had started a shell as sysadm_t and executed the rpm command.
Dan
On Mon, 2004-03-15 at 23:38 -0500, Daniel J Walsh wrote:
I have just modified sudo to exec $SHELL -c COMMAND when in SELinux mode.
What if SHELL=/home/rms/my_shell_that_ignores_-c_and_gives_prompt?
Rui Miguel Seabra wrote:
On Mon, 2004-03-15 at 23:38 -0500, Daniel J Walsh wrote:
I have just modified sudo to exec $SHELL -c COMMAND when in SELinux mode.
What if SHELL=/home/rms/my_shell_that_ignores_-c_and_gives_prompt?
It will not work. But this is a somewhat contrived situation, and easily worked around. I do not see this as a panacea, but required to get SELinux to work properly.
Dan
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On 15.03.2004 20:38, Daniel J Walsh wrote:
sudo_t transitions to another domain upon executing shell_exec_t. If you execute a binary that's not of type shell_exec_t then that doesn't work.
Is there a reason for that? This is kind of unfortunatye - one of the big advantages of sudo is that it logs everything and having to execute the shell first is kind of inconvenient. Can transition on an ordinary bin_t be added?
I have just modified sudo to exec $SHELL -c COMMAND when in SELinux mode.
This is indeed a big security hole - see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118602
This should cause the transitions to happen properly.
Nope.
audit(1079581466.332:0): avc: denied { transition } for pid=3247 exe=/usr/bin/sudo path=/bin/tcsh dev=hda2 ino=3662912 scontext=aleksey:staff_r:sudo_t tcontext=aleksey:system_r:sysadm_t tclass=process
on calling sudo -r system_r -t sysadm_t id
On Wed, 2004-03-17 at 23:13, Aleksey Nogin wrote:
on calling sudo -r system_r -t sysadm_t id
sysadm_r, not system_r.
On Fri, 2004-03-12 at 01:39, Aleksey Nogin wrote:
Well, sudo + sudoers does authenticate the "I am somebody who can act on behalf of the target user", why is this insufficient?
It might be sufficient (if you are willing to fully trust sudo and /etc/sudoers), although it would mean that you would lose the preservation of the SELinux user identity for its auditing on kernel operations. Your counterargument is presumably that sudo will log sufficiently (but again that presumes trust in sudo, and doesn't provide auditing on the kernel operations).
To do this, you would need to patch sudo to set the SELinux user identity to the new value; you cannot just use pam_selinux as is done for su, as the pam user identity is set to the old identity since that is the identity that is authenticated.
Do you expect everybody who are used to doing things via sudo (a lot of places where more than one user has admin access have policies insisting on sudo - in particular because sudo will log everything) to be willing to figure this out? Why is this information (e.g. "user x is allowed to act as root when re-authenticated") has to be listed in _two_ separate places (sudoers and policies)?
SELinux policy doesn't specify who is allowed to act as Linux uid 0 when re-authenticated. It does specify what roles you can enter. Whether or not sudo should change the SELinux user identity is certainly open to debate; we (NSA) didn't try integrating SELinux with sudo, so this is something that RH has to work out.
In order to have sudo safely change the SELinux user identity (to root), you would need another mechanism for specifying what roles/domains are permitted to the calling user, e.g. new fields in /etc/sudoers.
That would be the best solution IMHO. Should I file a Bugzilla RFE?
I'm in favor of being able to specify roles and domains in /etc/sudoers regardless of whether sudo changes the SELinux user identity.
Even then, you still need to start from staff_r in order to reach sysadm_r; the policy doesn't allow user_r to transition to sysadm_r (if SELinux is in enforcing mode).
Not sure I understand what you are saying - it works with su, why can't it be made to work with sudo?
It isn't permitted in the upstream policy, just the RH policy. user_r is more confined in the upstream policy.
On 11.03.2004 07:36, Stephen Smalley wrote:
Hence, if you add yourself to policy/users and authorize yourself for staff_r and sysadm_r and reload your policy, then you should be able to do sudo -r sysadm_r <command>.
What is the difference between the sysadm_r and system_r? When should I be using
sudo -r sysadm_r
and when
sudo -r system_r -t sysadm_t
? Thanks!
On Sat, 2004-03-13 at 15:53, Aleksey Nogin wrote:
On 11.03.2004 07:36, Stephen Smalley wrote:
Hence, if you add yourself to policy/users and authorize yourself for staff_r and sysadm_r and reload your policy, then you should be able to do sudo -r sysadm_r <command>.
What is the difference between the sysadm_r and system_r? When should I be using
sudo -r sysadm_r
and when
sudo -r system_r -t sysadm_t
You shouldn't need to do the latter ever.
I suspect that sudo should default to switching to sysadm_r, as that will be the expected behavior. It can use get_default_context to obtain a default context for the user and /etc/security/default_contexts can be set up to make it default to sysadm_r:sysadm_t.
On 18.03.2004 08:17, Stephen Smalley wrote:
What is the difference between the sysadm_r and system_r? When should I be using
sudo -r sysadm_r
and when
sudo -r system_r -t sysadm_t
You shouldn't need to do the latter ever.
So what is the difference between the sysadm_r and system_r? How does it relate to the
# sample for administrative user ifdef(`direct_sysadm_daemon', ` #user jadmin roles { staff_r sysadm_r system_r }; ', ` #user jadmin roles { staff_r sysadm_r }; ')
in the /etc/security/selinux/src/policy/users? Thanks!
I have done some major work today on sudo. Added an SELinux shell sesh. That does nothing but exec the command a second time. This will eliminate the globing problems.
I also have it automatically transitioning to sysadm_r if you are able to.
Sudo and policy rpm are required to make this work.
Dan
On Thu, 2004-03-18 at 13:43, Aleksey Nogin wrote:
So what is the difference between the sysadm_r and system_r? How does it relate to the
# sample for administrative user ifdef(`direct_sysadm_daemon', ` #user jadmin roles { staff_r sysadm_r system_r }; ', ` #user jadmin roles { staff_r sysadm_r }; ')
in the /etc/security/selinux/src/policy/users? Thanks!
sysadm_r is intended for administrative sessions. system_r is intended for system processes; it is the initial role for /sbin/init and its descendants. Including system_r in the set of role authorizations for administrators is a temporary workaround to support direct restarting of daemons from an admin shell; the daemon should then automatically transition into system_r:<daemon domain>, assuming it has a domain.
On Thu, 2004-03-11 at 10:36, Stephen Smalley wrote:
Even then, you still need to start from staff_r in order to reach sysadm_r; the policy doesn't allow user_r to transition to sysadm_r (if SELinux is in enforcing mode).
Ah, my mistake - the Fedora Core devel policy allows this transition unless you disable the unlimitedUsers tunable.
selinux@lists.fedoraproject.org
-
Aleksey Nogin -
Daniel J Walsh -
Doug Nicholson -
Jeff Johnson -
Rui Miguel Silva Seabra -
Russell Coker -
Stephen Smalley