On Fri, 2010-01-22 at 10:13 +0000, TaurusHarry wrote: > Exactly! Aside from missing necessary TE rules another possible reason > program can't run normally is that the file accessed has not been > properly labeled. My above findings that many types have no "search" > privilege against the tmpfs_t is a good example of this: none > of /dev/* should be labeled as tmpfs_t. From my below findings we can > see that tmpfs have been mounted to both /dev and /dev/shm, and after > booting with enforcing=0, /dev/stderr and etc are labeled as tmpfs_t, > but after I manually do restorecon -R /dev, they will all reclaim > their correct labels: > > root@cp3020:/root> cat /proc/cmdline > root=/dev/sda1 rw console=ttyS0,115200n8 ip=dhcp selinux=1 enforcing=0 > BOOT_IMAGE=/vlm-boards/12885/qcao/kernel > root@cp3020:/root> cat /proc/mounts > rootfs / rootfs rw 0 0 > /dev/root / ext2 rw,errors=continue 0 0 > none /selinux selinuxfs rw 0 0 > /proc /proc proc rw 0 0 > /sys /sys sysfs rw 0 0 > none /dev tmpfs rw,mode=755 0 0 > devpts ! /dev/pts devpts rw,mode=600 0 0 > tmpfs /dev/shm tmpfs rw 0 0 > none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 > root@cp3020:/root> ls -Z /dev/ | grep tmpfs_t > lrwxrwxrwx root root system_u:object_r:tmpfs_t:s0 MAKEDEV > drwxr-xr-x root root system_u:object_r:tmpfs_t:s0 bsg > lrwxrwxrwx root root system_u:object_r:tmpfs_t:s0 core > drwxr-xr-x root root system_u:object_r:tmpfs_t:s0 cpu > drwxr-xr-x root root system_u:object_r:tmpfs_t:s0 disk > lrwxrwxrwx root root system_u:object_r:tmpfs_t:s0 fd > crw------- root root system_u:object_r:tmpfs_t:s0 ipmi0 > srw-rw-rw- root root system_u:object_r:tmpfs_t:s15:c0.c255 log > drwxrwxrwt root root system_u:object_r:tmpfs_t:s0 shm > lrwxrwxrwx root root system_u:object_r:tmpfs_t:s0 stderr > lrwxrwxrwx root ro! ot system_u:object_r:tmpfs_t:s0 stdin > lrwxrwxrwx root root system_u:object_r:tmpfs_t:s0 stdout > root@cp3020:/root> /sbin/restorecon -R /dev > root@cp3020:/root> ls -Z /dev | grep tmpfs_t > root@cp3020:/root> ls -Z /dev | grep -v device_t > prw------- root root system_u:object_r:initctl_t:s0 initctl > srw-rw-rw- root root system_u:object_r:devlog_t:s0 log > crw-rw-rw- root tty system_u:object_r:ptmx_t:s0 ptmx > drwxr-xr-x root root system_u:object_r:devpts_t:s0-s15:c0.c255 pts > crw-rw-rw- root tty system_u:object_r:devtty_t:s0 tty > root@cp3020:/root> > > However, after reboot the console still hangs. I think many files > under /dev/ are created by udev on-the-fly so we have to label them > after creation. Then I modified rc.sysinit to move "/sbin/restorecon > -R /dev" out of the c! ontrol of the if statement and thus always be > conducted, but the probl em is still there. I even went on to > touch /.autorelabel and changed "/sbin/fixfiles restore > /dev/null > 2>&1" to "/sbin/restorecon -R /" in the relabel_selinux() function(so > that the whole filesystem is relabeled once again during bootup), but > the problem still persists. > > Any further comments? The restorecon -R /dev has to be done on every boot since tmpfs is ephemeral. There are certain allow rules that are only included if DISTRO=redhat related to relabeling of the tmpfs /dev I believe, as some other distros took a different approach (mounting with rootcontext=?)? -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
