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 与任何您希望的人分享您的回忆。 任何您希望的人。 |