Currently sec-policy/selinux-sudo does not allow access to /etc/selinux/strict/contexts/default_type. This causes sudo -s or sudo -i to fail if the type is not specified with the -t switch. iax /home/stan $sudo -s stan's password: sudo: unable to get default type for role sysadm_r sudo: unable to execute /bin/bash: Invalid argument iax /home/stan $sudo -st sysadm_t iax /home/stan # Feb 1 20:21:15 iax kernel: type=1400 audit(1359775275.969:63): avc: denied { read } for pid=3176 comm="sudo" name="default_type" dev="sda3" ino=6311437 scontext=stan:staff_r:staff_sudo_t tcontext=system_u:object_r:default_context_t tclass=file sesearch shows the necessary permissions are there for the directory, but not the file. allow staff_sudo_t default_context_t : dir { getattr search open } ; This makes me think the lack of file class permissions is an oversight. Assuming the default type is what I want, I shouldn't have to specify the type on the command line.
Hi Stan, I'm not able to reproduce this here... """ swift@hpl ~ $ sudo -s bash: /root/.bashrc: Permission denied hpl swift # id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) context=staff_u:staff_r:staff_t hpl swift # """ I agree that it is very likely that sudo needs to read the file, but the behavior is important as well. Adding seutil_read_default_contexts(sudodomain) doesn't change anything here.
hmmm.....interesting. This is on an x86 stable profile so the version is sec-policy/selinux-sudo-2.20120725-r9 Not sure if that makes any difference. Also interesting that staff_t CAN read the file, but staff_sudo_t can't. Also staff_t has more perms than the staff_sudo_t, but that's probably not significant. #sesearch -s staff_t -t default_context_t -ACd Found 2 semantic av rules: allow staff_t default_context_t : file { ioctl read getattr lock open } ; allow staff_t default_context_t : dir { ioctl read getattr lock search open } ; sesearch -s staff_sudo_t -t default_context_t -ACd Found 1 semantic av rules: allow staff_sudo_t default_context_t : dir { getattr search open } ; After a successful sudo -st sysadm_t here is what I show for id: #id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),11(floppy),26(tape),27(video) context=stan:sysadm_r:sysadm_t which differs slightly from yours in that your id still showed that you did not get sysadm_r and sysadm_t even though you are root. Here are the relevant SELinux user definitions: root staff_r sysadm_r system_r staff_u staff_r sysadm_r stan staff_r sysadm_r system_r Could I be missing something in my SELinux user definition, or did something not load up correctly in my policy somehow? I just don't get what could be causing the difference.
It might have to do with the sudoers file (do you have any type/role declarations in it?). It is normal that the staff_sudo_t is much less privileged than staff_t: it is a "jumping domain" so that, if staff_t executes sudo_t, then staff_sudo_t is used which then automatically transforms back to staff_t on executing binaries. Without such a jumping domain, the policies don't know if sudo_t needs to transition back to staff_t or sysadm_t or another domain.
Yes, I do have a sysadm_r declaration for my account, but no type is specified.
Sorry hit submit too quickly. I added the type=sysadm_t to the configuration and it now functions the way I intended/want. Seems that in times past it worked OK without the type being declared in the config, but I won't swear to it!! Anyways, probably fair to mark this as WONTFIX.
Yes, and who knows the fix gets in upstream later anyhow. But for now, I'd be hard for me to "defend" the fix.
