From: harrytaurus2002@hotmail.com (TaurusHarry) Date: Mon, 25 Jan 2010 09:32:51 +0000 Subject: [refpolicy] Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken In-Reply-To: References: , , , , <4B53CEB9.3050207@gmail.com>, , , , , <4B543977.40007@gmail.com>, , , , , <4B550EB9.50806@gmail.com>, , , , <1264079995.11002.19.camel@moss-pluto.epoch.ncsc.mil>, , , , <1264176847.22211.16.camel@moss-pluto.epoch.ncsc.mil>, Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hi Stephen and Justin, I have got some new findings after I sent out the previous email. The weird error messages about /var/lock/subsys/ turns out to be hard disk inconsistency problem and could be fixed by fsck.ext2, after that, find and touch performed by rc.sysinit or /etc/rc3.d/* would have no problem at all :-) However, my console still hangs at "INIT: Id "0" respawning too fast: disabled for 5 minutes", although so far I think I have fixed all those obvious problems with SELinux during boot up and I could no longer find fishy AVC denied message except something like: type=1400 audit(1264435478.992:5): avc: denied { rawip_send } for pid=5 comm="sirq-timer/0" saddr=fe80:0000:0000:0000:0203:baff:fef1:73e3 daddr=ff02:0000:0000:0000:0000:0000:0000:0002 netif=eth5 scontext=system_u:system_r:kernel_t:s15:c0.c255 tcontext=system_u:object_r:netif_t:s0-s15:c0.c255 tclass=netif type=1400 audit(1264435478.992:6): avc: denied { rawip_send } for pid=5 comm="sirq-timer/0" saddr=fe80:0000:0000:0000:0203:baff:fef1:73e3 daddr=ff02:0000:0000:0000:0000:0000:0000:0002 netif=eth5 scontext=system_u:system_r:kernel_t:s15:c0.c255 tcontext=system_u:object_r:node_t:s0-s15:c0.c255 tclass=node But I don't think they could be the reason /sbin/init would fail to run /sbin/mingetty. Then I came up with the idea to toggle SELinux state into Permissive mode in the rc.local and finally the console on longer hangs and I could login normally: root at cp3020:/root> cat /proc/cmdline root=/dev/sda1 rw console=ttyS0,115200n8 ip=dhcp selinux=1 BOOT_IMAGE=/vlm-boards/12885/qcao/kernel root at cp3020:/root> getenforce Permissive root at cp3020:/root> root at cp3020:/root> cat /var/log/messages ... Jan 25 16:59:15 cp3020 /etc/rc3.d/S95atd: atd startup - OK Jan 25 16:59:15 cp3020 boot: Starting cracklibd Jan 25 16:59:16 cp3020 boot: Starting local Jan 25 16:59:16 cp3020 kernel: type=1404 audit(1264438756.016:4): enforcing=0 ol d_enforcing=1 auid=4294967295 ses=4294967295 ... root at cp3020:/root> We can see selinux does boot up WITH enforcing=1 but toggled into enforcing=0 at rc.local, which proves that all my left problem focused on /sbin/mingetty 0:2345:respawn:/sbin/mingetty console (in my /etc/inittab) Maybe I need to identify the changes from refpolicy-2.20081210 to refpolicy-2.20091117 related with getty_t. Best regards, Harry From: harrytaurus2002@hotmail.com To: sds at tycho.nsa.gov Date: Mon, 25 Jan 2010 06:04:16 +0000 CC: refpolicy at oss1.tresys.com; selinux at tycho.nsa.gov Subject: Re: [refpolicy] Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken Hi Stephen and Justin, The OS I am using is very similar to RedHat and I have set DISTRO=redhat. I found this report last weekend: https://bugzilla.redhat.com/show_bug.cgi?id=425832, which confirmed that if the tmpfs mounted on /dev has not been properly labeled once mounted, MAKEDEV -x on /dev would generate following error message: Start udev: MAKEDEV: mkdir: File exist Well, this is exactly the same error message I got, and I'd confirmed in my previous email that after log in with enforcing=0, "ls -Z /dev" reveals that /dev has not been labeled, many nodes such as log/stderr etc are still labeled with tmpfs_t. As suggested by another bug report of http://74.125.153.132/search?q=cache:hTh0mCacXPEJ:bugs.debian.org/564196+restoerecon+-R+/dev&cd=2&hl=en&ct=clnk&client=firefox-a, I added "/sbin/restorecon /dev" in /sbin/start_udev after this script mount tmpfs on /dev: # mount the tmpfs on ${udev_root%/}, if not already done LANG=C awk "\$2 == \"${udev_root%/}\" && \$3 == \"tmpfs\" { exit 1 }" /proc/moun ts && { if LANG=C fgrep -q "none ${udev_root%/}/pts " /proc/mounts; then PTSDIR=$(mktemp -d) mount --move $udev_root/pts "$PTSDIR" fi if LANG=C fgrep -q "none ${udev_root%/}/shm " /proc/mounts; then SHMDIR=$(mktemp -d) mount --move $udev_root/shm "$SHMDIR" fi mount -n -o mode=0755 -t tmpfs none "$udev_root" + if [ -n "$selinuxfs" ]; then + /sbin/restorecon /dev > /dev/null 2>&1 + fi mkdir -m 0755 $udev_root/pts mkdir -m 0755 $udev_root/shm if [ -n "$PTSDIR" ]; then mount --move "$PTSDIR" $udev_root/pts rmdir "$PTSDIR" fi if [ -n "$SHMDIR" ]; then mount --move "$SHMDIR" $udev_root/shm rmdir "$SHMDIR" fi ret=$[$ret + $?] } Then the original MAKEDEV error message disappears, but threw up another error message: Starting udev: MAKEDEV: error making /dev/loop0: Permission denied The relevant AVC deneid message implies that initrc_t has no "create" privilege against the fixed_disk_device_t type, so I went on to call storage_tmpfs_filetrans_fixed_disk() interface against initrc_t for the Red Hat distribution: @@ -477,6 +477,7 @@ ifdef(`distro_redhat',` storage_manage_fixed_disk(initrc_t) storage_dev_filetrans_fixed_disk(initrc_t) storage_getattr_removable_dev(initrc_t) + &nbs p; storage_tmpfs_filetrans_fixed_disk(initrc_t) # readahead asks for these auth_dontaudit_read_shadow(initrc_t) BTW, this interface has been called against the distro_debian, so I guess we may need to do it for Red Hat too. What would you think? With the above two changes MAKEDEV could finally run uneventfully. However, I run into some other new error messages: Start udev: [OK] ... Enabling local filesystem quotas: [ OK ] find: /var/lock/subsys/ipmi: Stale NFS file handle find: /var/lock/subsys/portmap: Stale NFS file handle find: /var/lock/subsys/netfs: Stale NFS file handle find: /var/lock/subsys/ocfs2: Stale NFS file handle find: /var/lock/subsys/sshd: Stale NFS file handle ... find: /var/run/evlnotifyd.pid: Stale NFS file handle find: /var/run/sm-client.pid: Stale NFS file handle find: /v ar/run/sendmail.pid: Stale NFS file handle find: /var/run/crond.pid: Stale NFS file handle find: /var/run/evlactiond.pid: Stale NFS file handle Enabling /etc/fstab swaps: [ OK ] INIT: Entering runlevel: 3 ... Starting portmap: [ OK ] touch: cannot touch `/var/lock/subsys/portmap': Stale NFS file handle touch: cannot touch `/var/lock/subsys/netfs': Stale NFS file handle Mounting other filesystems: [ OK ] touch: cannot touch `/var/lock/subsys/ocfs2': Stale NFS file handle touch: cannot touch `/var/lock/subsys/sshd': Stale NFS file handle ... Starting sm-client: touch: cannot touch `/var/run/sm-client.pid': Stale NFS file handle chown: cannot access `/var/run/sm-client.pid': Stale NFS file handle /sbin/restorecon: lstat(/var/run/sm-client.pid) failed: Stale NFS file handle [ OK ] touch: cannot touch `/var/lock/subsys/sm-client': Stale NFS file handle tou ch: cannot touch `/var/lock/subsys/boa': Stale NFS file handle ... Starting crond: [FAILED] Starting notification action daemon: [ OK ] touch: cannot touch `/var/lock/subsys/evlaction': Stale NFS file handle Starting atd: [FAILED] touch: cannot touch `/var/lock/subsys/local': Stale NFS file handle INIT: Id "0" respawning too fast: disabled for 5 minutes INIT: no more processes left in this runlevel INIT: Id "0" respawning too fast: disabled for 5 minutes (console hangs ...) I am booting from local hard disk not NFS rootfs. These strange error messages are thrown by the find command in rc.sysinit when it is trying to clean up /var and /etc/rc3.d/* initscripts when they are trying to touch their lock files under /var/lock/subsys/. Moreover, after log in with enforcing=0, "ls -Z /var/lock/subsys/" reveals that despite lock files created(in Permissive mode) under /var/lock/subsys/, their DAC attributes, uid/gid, SELinux security contexts have not been correctly created, and I am even unable to correct them by restorecon: root at cp3020:/root> ls -Z /var/lock/subsys/ ls: cannot access /var/lock/subsys/ipmi: Stale NFS file handle ls: cannot access /var/lock/subsys/portmap: Stale NFS file handle ls: cannot access /var/lock/subsys/netfs: Stale NFS file handle ls: cannot access /var/lock/subsys/ocfs2: Stale NFS file handle ls: cannot access /var/lock/subsys/sshd: Stale NFS file handle ... ls: cannot access /var/lock/subsys/local: Stale NFS file handle -rw-r--r-- root root system_u:object_r:var_lock_t atd ?--------- ? ? boa ?--------- ? ? &nb sp; crond ?--------- ? ? evlaction ?--------- ? ? evlnotify -rw------- root root system_u:object_r:var_lock_t evlog -rw------- root root system_u:object_r:var_lock_t evlogrmt ?--------- ? ? ; ipmi ?--------- ? ? iscsid ?--------- ? ? local ?--------- ? ? netfs ?---------&n bsp; ? ? ocfs2 ?--------- ? ? portmap ?--------- ? ? sendmail ?--------- ? ? &nbs p; sm-client ?--------- ? ? sshd -rw------- root root system_u:object_r:var_lock_t syslog-ng ?--------- ? ? xinetd root at cp3020:/root> restorecon -R /var/lock/subsys/ restorecon get context on /var/lock/subsys/ipmi failed: 'Stale NFS file handle' restorecon get context on /var/lock/subsys/portmap failed: 'Stale NFS file handle' restorecon get context on /var/lock/subsys/netfs failed: 'Stale NFS file handl e' restorecon get context on /var/lock/subsys/ocfs2 failed: 'Stale NFS file handle' restorecon get context on /var/lock/subsys/sshd failed: 'Stale NFS file handle' ... restorecon get context on /var/lock/subsys/local failed: 'Stale NFS file handle' root at cp3020:/root> Any ideas why some lock files are broken while the rest is correct? Thank you very much! Best regards, Harry ??????????MSN??? ????? _________________________________________________________________ SkyDrive????????????????????????! http://www.windowslive.cn/campaigns/e-magazine/ngmchina/?a=c -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100125/2e4de8fe/attachment-0001.html