Questions about TE rules in refpolicy-20081210

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Smalley,

Thank you very much for the selinux kernel patch, after applying it I finally could boot up refpolicy-20081210 uneventfully - all error messages about udevd and mingetty are simply disappeared!

Well, when I play with refpolicy-20081210 with MLS enabled, I run into several issues and I am not clear if they are deliberately designed to be this way or they might be potential problems, I certainly don't want to open any security holes so I would very much like to discuss with you about them, thanks again!

1, after log in, if I do "mount" then it will display nothing, neither "cat /etc/mtab" would show anything;

I think this is due to the mount_t type has no rights to write into /etc/mtab, which is of etc_runtime_t type.
I know we have called files_manage_etc_runtime_files(mount_t) in mount.te, but only after I added files_rw_etc_runtime_files(mount_t) would the mount program be able to write into /etc/mtab. Also, we may have to call fil! es_manage_generic_locks(mount_t) so that mount_t could grab related /var/lock/mtab~ successfully.

The whole scenario is logged below and the patch is attached:

root@d610-2:/root> id -Z
root:sysadm_r:sysadm_t:s0-s15:c0.c255
root@d610-2:/root> semodule -u mount.pp
semodule: SELinux policy is not managed or store cannot be accessed.
root@d610-2:/root> semodule -l | grep mount
semodule: SELinux policy is not managed or store cannot be accessed.
root@d610-2:/root> newrole -r secadm_r
Password:
bash: /root/.profile: Permission denied
root@d610-2:~# /usr/sbin/semodule -l | grep mount
automount    1.11.0
mount    1.10.0
root@d610-2:~# /usr/sbin/semodule -u mount.pp
/usr/sbin/semodule:  Could not read file 'mount.pp': Permission denied
root@d610-2:~# /usr/sbin/getenforce
Enforcing
root@d610-2:~# /usr/sbin/setenforce 0
root@d610-2:~# /usr/sbin/getenforce
Permissiveroot@d610-2:~# /usr/sbin/semodule -u mount.pp
root@d610-2:~# /u sr/sbin/semodule -l | grep mount
automount    1.11.0
mount    1.10.1        # updated!!!
root@d610-2:~# mount
root@d610-2:~# cat /etc/mtab
root@d610-2:~# /sbin/reboot
(rebooting...)
root@d610-2:/root> id -Z
root:sysadm_r:sysadm_t:s0-s15:c0.c255
root@d610-2:/root> getenforce
Enforcing
root@d610-2:/root> mount
rootfs on / type rootfs (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw)
tmpfs on /dev/shm type tmpfs (rw)
root@d610-2:/root> cat /etc/mtab
rootfs / rootfs rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
root@d610-2:/root>

2, if log in the root user through serial console, I would be unable to assume another administrator roles(auditadm_r, secadm_r) by the newrole program, the error message says that newrole! is unable to relabel the /dev/console device.

So far the contents of the securetty_types file are all about X_tty_device_t, where X could be of any administrator's role or staff or unprivileged user, it would be enough if log in through local /dev/ttyN device by Ctl+Alt+FN. However, if I want to use newrole on the serial console, I think I would have to mark it as secure device by appending its type of console_device_t to the securetty_types file.

Aside from that, I have to call term_relabel_console(newrole_t) so that newrole_t would have necessary permissions to relabelto or relabelfrom the /dev/console.

The patch is attched.

3, The /root/ directory is used to be labeled as "sysadm_home_t" or "sysadm_home_dir_t", but I found them are labeled as default_t now and it seems that only the sysadm_t has read permission to the /root/ directory. If I assume another administrator role such as secadm_r, then secadm_t would have trouble to read or write /! root/:

root@d610-2:/root> id -Z
root:sysadm_r:sysadm_t:s0 -s15:c0.c255
root@d610-2:/root> newrole -r secadm_r
Password:
bash: /root/.profile: Permission denied    
root@d610-2:~# id -Z
root:secadm_r:secadm_t:s0-s15:c0.c255
root@d610-2:~# touch 1
touch: cannot touch `1': Permission denied
root@d610-2:~#

Shouldn't secadm_t and auditadm_t also have enough rights to the /root/ directory?

Looking forward to any of your comments!

Best regards,

Harry



与任何您希望的人分享您的回忆。 任何您希望的人。

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux