From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Content-Type: multipart/alternative; boundary="_9916c639-9eed-432a-9d5a-5f6e59652dad_" From: TaurusHarry To: Stephen Smalley CC: , selinux-mailing-list Subject: RE: [refpolicy] Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken Date: Mon, 25 Jan 2010 09:32:51 +0000 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>, MIME-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --_9916c639-9eed-432a-9d5a-5f6e59652dad_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit 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@cp3020:/root> cat /proc/cmdline root=/dev/sda1 rw console=ttyS0,115200n8 ip=dhcp selinux=1 BOOT_IMAGE=/vlm-boards/12885/qcao/kernel root@cp3020:/root> getenforce Permissive root@cp3020:/root> root@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@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@tycho.nsa.gov Date: Mon, 25 Jan 2010 06:04:16 +0000 CC: refpolicy@oss1.tresys.com; selinux@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@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@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@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 --_9916c639-9eed-432a-9d5a-5f6e59652dad_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit 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@cp3020:/root> cat /proc/cmdline

root=/dev/sda1 rw console=ttyS0,115200n8 ip=dhcp selinux=1 BOOT_IMAGE=/vlm-boards/12885/qcao/kernel

root@cp3020:/root> getenforce

Permissive

root@cp3020:/root>

root@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@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@tycho.nsa.gov
Date: Mon, 25 Jan 2010 06:04:16 +0000
CC: refpolicy@oss1.tresys.com; selinux@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 doneLANG=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=075! 5 -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)
+  &am! p;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@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
?---------  ?    ?     &a! mp;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
?---------  ?    ?      &nbs! p; ;                              ipmi
?---------  ?    ?                                     iscsid
?---------  ?    ?                                     local
?---------  ?    ?                                     netfs
?---------&! amp;n bsp; ?    ?                                     ocfs2
?---------  ?    ?                                     portmap
?---------  ?    ?                                     sendmail
?---------  ?    ?                           &am! p;nbs p;         sm-client
?---------  ?    ?                                     sshd
-rw-------  root root system_u:object_r:var_lock_t     syslog-ng
?---------  ?    ?                                     xinetd
root@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@cp3020:/root>

Any ideas why some lock files are broken while the rest is correct?

Thank you very much!

Best regards,
Harry

更多热辣资讯尽在新版MSN首页！ 立刻访问！
聊天+搜索+邮箱 想要轻松出游,手机MSN帮你搞定! 立刻下载！ --_9916c639-9eed-432a-9d5a-5f6e59652dad_-- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 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