On Thu, 2010-01-21 at 09:36 +0000, TaurusHarry wrote:
> Hi Justin,
>
> Sorry I respond late, thanks a lot for you to remind to first boot
> SELinux into Permissive mode then analyze the AVC denied messages and
> try to supplement necessary rules, I think it is indeed the
> once-and-for-all solution to any problem of missing SELinux rules.
>
> It took me two days to come up with following rules that may be
> desirable to the refpolicy-2.20091117: (or to use dontaudit if they
> are expected redundant behaviors)
>
> +allow crond_t self:capability { dac_override setgid setuid sys_nice
> dac_read_search audit_control };
>
> +corecmd_bin_domtrans(crond_t)
> +hostname_domtrans(crond_t)
> +corecmd_getattr_bin_files(crond_t)
> +corecmd_exec_bin(crond_t)
> +corecmd_manage_bin_files(crond_t)
> +fs_search_tmpfs(crond_t)
> +fs_manage_tmpfs_sockets(crond_t)
>
> +dontaudit quota_t self:memprotect { mmap_zero} ;
>
> +fs_search_tmpfs(getty_t)
>
> +term_use_console(insmod_t)
>
> +fs_search_tmpfs(iscsid_t)
> +fs_manage_tmpfs_sock! ets(iscsid_t)
>
> +files_rw_lock_dirs(mount_t)
> +files_manage_generic_locks(mount_t)
>
> +fs_search_tmpfs(pam_console_t)
> +fs_getattr_tmpfs_dirs(pam_console_t)
> +fs_manage_tmpfs_dirs(pam_console_t)
>
> +fs_search_tmpfs(portmap_t)
>
> +/root -d gen_context(system_u:object_r:user_home_dir_t,s0)
> +/root/.+ gen_context(system_u:object_r:user_home_t,s0)
>
> +fs_search_tmpfs(sendmail_t)
> +fs_manage_tmpfs_sockets(sendmail_t)
>
> +term_read_console(setfiles_t)
>
> +fs_search_tmpfs(syslogd_t)
> +fs_manage_tmpfs_dirs(syslogd_t)
> +fs_manage_tmpfs_sockets(syslogd_t)
>
> +fs_search_tmpfs(sysstat_t)
>
> (BTW, why there are so many types that have missed the "search"
> privilege against tmpfs_t? Any convenient way to solve this problem
> than invoking fs_search_tmpfs() against each type individually?)
>
> I've tried my best to translate as many AVC denied mess! ages to
> SELinux rules as possible, however, even with all above additi onal
> rules applied, I still can't log in SELinux in Enforcing mode(the
> console stuck with "INIT: Id "0" respawning too fast: disabled for 5
> minutes"), and there is NOT a single AVC denied message I could find
> any more by dmesg after log in with enforcing=0! I really don't get
> it :-(
>
> What could I have missed out? So far all I know is that neither the
> kernel nor the SELinux tools I used are latest, my kernel is 2.6.27
> and SELinux tools are of "Release 2009-04-03". Do I need to update
> kernel and SElinux tools in order to use refpolicy-2.20091117? What
> can I do now to solve this problem?
>
> BTW, I've compiled refpolicy-2.20091117 with "TYPE = standard", while
> I originally wanted to try out the MLS type. I uuss I have to overcome
> the standard type problem before moving on to the MLS type.
>
> Any comment is greatly appreciated!
refpolicy questions go to refpolicy at oss.tresys.com (cc'd).
I would recommend updating your SELinux userspace to the latest released
version and rebuilding your policy, and also booting permissive and
performing a complete filesystem relabel.
Your tmpfs denials suggest that you have a tmpfs mount that is not being
properly labeled. For example, if you are using a tmpfs mount on /dev,
then it usually needs to have restorecon -R /dev applied during early
boot (from rc.sysinit in Fedora) or to be mounted with a rootcontext=
option. ls -Z /dev would be interesting, as would cat /proc/mounts.
--
Stephen Smalley
National Security Agency
Hi Stephan and Justin,
Thank you very much for you suggestions, please see my further findings embedded below,
Best regards,
Harry
> Subject: RE: Bootup problem with refpolicy-2.20091117 - rules found but still can't login
> From: sds at tycho.nsa.gov
> To: harrytaurus2002 at hotmail.com
> CC: justinmattock at gmail.com; selinux at tycho.nsa.gov; refpolicy at oss1.tresys.com
> Date: Thu, 21 Jan 2010 08:19:55 -0500
>
> On Thu, 2010-01-21 at 09:36 +0000, TaurusHarry wrote:
> > Hi Justin,
> >
> > Sorry I respond late, thanks a lot for you to remind to first boot
> > SELinux into Permissive mode then analyze the AVC denied messages and
> > try to supplement necessary rules, I think it is indeed the
> > once-and-for-all solution to any problem of missing SELinux rules.
> >
> > It took me two days to come up with following rules that may be
> > desirable to the refpolicy-2.20091117: (or to use dontaudit if they
> > are expected redundant behaviors)
> >
> > +allow crond_t self:capability { dac_override setgid setuid sys_nice
> > dac_read_search audit_control };
> >
> > +corecmd_bin_domtrans(crond_t)
> > +hostname_domtrans(crond_t)
> > +corecmd_getattr_bin_files(crond_t)
> > +corecmd_exec_bin(crond_t)
> > +corecmd_manage_bin_files(crond_t)
> > +fs_search_tmpfs(crond_t)
> > +fs_manage_tmpfs_sockets(crond_t)
> >
> > +dontaudit quota_t self:memprotect { mmap_zero} ;
> >
> > +fs_search_tmpfs(getty_t)
> >
> > +term_use_console(insmod_t)
> >
> > +fs_search_tmpfs(iscsid_t)
> > +fs_manage_tmpfs_sock! ets(iscsid_t)
> >
> > +files_rw_lock_dirs(mount_t)
> > +files_manage_generic_locks(mount_t)
> >
> > +fs_search_tmpfs(pam_console_t)
> > +fs_getattr_tmpfs_dirs(pam_console_t)
> > +fs_manage_tmpfs_dirs(pam_console_t)
> >
> > +fs_search_tmpfs(portmap_t)
> >
> > +/root -d gen_context(system_u:object_r:user_home_dir_t,s0)
> > +/root/.+ gen_context(system_u:object_r:user_home_t,s0)
> >
> > +fs_search_tmpfs(sendmail_t)
> > +fs_manage_tmpfs_sockets(sendmail_t)
> >
> > +term_read_console(setfiles_t)
> >
> > +fs_search_tmpfs(syslogd_t)
> > +fs_manage_tmpfs_dirs(syslogd_t)
> > +fs_manage_tmpfs_sockets(syslogd_t)
> >
> > +fs_search_tmpfs(sysstat_t)
> >
> > (BTW, why there are so many types that have missed the "search"
> > privilege against tmpfs_t? Any convenient way to solve this problem
> > than invoking fs_search_tmpfs() against each type individually?)
> >
> > I've tried my best to translate as many AVC denied mess! ages to
> > SELinux rules as possible, however, even with all above additi onal
> > rules applied, I still can't log in SELinux in Enforcing mode(the
> > console stuck with "INIT: Id "0" respawning too fast: disabled for 5
> > minutes"), and there is NOT a single AVC denied message I could find
> > any more by dmesg after log in with enforcing=0! I really don't get
> > it :-(
> >
> > What could I have missed out? So far all I know is that neither the
> > kernel nor the SELinux tools I used are latest, my kernel is 2.6.27
> > and SELinux tools are of "Release 2009-04-03". Do I need to update
> > kernel and SElinux tools in order to use refpolicy-2.20091117? What
> > can I do now to solve this problem?
> >
> > BTW, I've compiled refpolicy-2.20091117 with "TYPE = standard", while
> > I originally wanted to try out the MLS type. I uuss I have to overcome
> > the standard type problem before moving on to the MLS type.
> >
> > Any comment is greatly appreciated!
>
> refpolicy questions go to refpolicy at oss.tresys.com (cc'd).
>
> I would recommend updating your SELinux userspace to the latest released
> version and rebuilding your policy, and also booting permissive and
> performing a complete filesystem relabel.
>
Yeah, I have updated to the latest SELinux userspace tools of Release 2009-11-23 and do restorecon -R / after loggin in with enforcing=0, but console still hangs if enforcing=1.
> Your tmpfs denials suggest that you have a tmpfs mount that is not being
> properly labeled. For example, if you are using a tmpfs mount on /dev,
> then it usually needs to have restorecon -R /dev applied during early
> boot (from rc.sysinit in Fedora) or to be mounted with a rootcontext=
> option. ls -Z /dev would be interesting, as would cat /proc/mounts.
>
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 at 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 at 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 at 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 root system_u:object_r:tmpfs_t:s0 stdin
lrwxrwxrwx root root system_u:object_r:tmpfs_t:s0 stdout
root at cp3020:/root> /sbin/restorecon -R /dev
root at cp3020:/root> ls -Z /dev | grep tmpfs_t
root at 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 at 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 control of the if statement and thus always be conducted, but the problem 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?
Thanks!
Harry
> --
> 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 at tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
_________________________________________________________________
MSN????????MSN???????????
http://10.msn.com.cn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100122/93599a00/attachment.html
hmm.. im wondering if this due to init
or upstart or even farther down the line with gdm.
what system are you using?
Justin P. Mattock
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 at 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 at 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 at 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 at cp3020:/root> /sbin/restorecon -R /dev
> root at cp3020:/root> ls -Z /dev | grep tmpfs_t
> root at 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 at 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
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)
+ 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: /var/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
touch: 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
?--------- ? ? 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
?--------- ? ? ocfs2
?--------- ? ? portmap
?--------- ? ? sendmail
?--------- ? ? 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 handle'
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?????
http://ditu.live.com/?form=TL&swm=1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100125/5fa9bbef/attachment.html
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: [email protected]
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
On Mon, 2010-01-25 at 09:32 +0000, TaurusHarry wrote:
> 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
Hmm..so you don't have secmark enabled by default? Kernel config?
> 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.
Rebuild policy with dontaudits removed (semodule -DB) and retry, then
look for audit messages involving getty.
--
Stephen Smalley
National Security Agency
Hi Stephen,
With all the kind help from you and Justin, I finally made the latest refpolicy-2.20091117 boot up successfully! Hat off for you two :-)
Please see my embedded replies, thanks!
> Subject: RE: [refpolicy] Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken
> From: sds at tycho.nsa.gov
> To: harrytaurus2002 at hotmail.com
> CC: refpolicy at oss1.tresys.com; selinux at tycho.nsa.gov
> Date: Mon, 25 Jan 2010 10:35:45 -0500
>
> On Mon, 2010-01-25 at 09:32 +0000, TaurusHarry wrote:
> > 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
>
> Hmm..so you don't have secmark enabled by default? Kernel config?
$ grep SECMARK linux-sun_cp3020-cgl-build/.config
CONFIG_NETWORK_SECMARK=y
# CONFIG_NETFILTER_XT_TARGET_SECMARK is not set
$
More secmark options should I enable?
>
> > 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.
>
> Rebuild policy with dontaudits removed (semodule -DB) and retry, then
> look for audit messages involving getty.
Yeah, I created a policy store and then do semodule -DB and reboot, I found AVC denied messages about domains of sendmail_t, hostname_t, quota_t, dmesg_t lack the read privilege against console_device_t, which is expected because we have called term_dontaudit_use_console() interface for these domains.
Since so far we have identified that my problem is rooted with getty_t, so I went on to take a quick glance at getty.te and very suprisingly found this dontaudit interface has been called for getty_t too! For me I am trying to login my target through a serial console, rather than any tty device, so I assume the getty_t should be granted all necessary privileges to operate the console. Once I removed the term_dontaudit_use_console(getty_t) I could find following AVC denied message:
type=1400
audit(1264520547.936:68): avc: denied { noatsecure } for pid=2292
comm="login"
scontext=system_u:system_r:getty_t:s0-s15:c0.c255
tcontext=system_u:system_r:local_login_t:s0-s15:c0.c255
tclass=process
which I guess is right the root cause to my problem. Once I replaced it by term_use_console(getty_t), I finally could login successfully!
This problem made me sleepless for like 10 days and I would like to take this opportunity to summarize it here:
1. use enforcing=0 bootparam if unable to login selinux, then dmesg all those AVC denied messages for potential extra TE rules;
2. problem could be caused by files not being properly labeled, as well as necessary TE rules are missing. In my case many domains has no search right against tmpfs_t, however, tmpfs_t doesn't exist even in file_contexts, this indicates tmpfs filesystem has not been properly labeled. It turns out start_udev should have labeled tmpfs once it mounts tmpfs on /dev;
3, if perblem persists but no relevant AVC denied messsage could be referenced, use semodule -DB to rebuild policy and remove all those dontaudit rules, or remove the call to some dontaudit interface in the related .te, so thar SELinux could throw out as many AVC denied messages as possible.
Next, I will go on play with the latest refpolicy package and bring up the extra necessary TE rules I find.
Thank you so very much, again!
Best regards,
Harry
>
> --
> 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 at tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
_________________________________________________________________
?Windows Live ???????Messenger2009????
http://www.windowslive.cn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100126/bbace159/attachment-0001.html
On 01/26/10 00:50, TaurusHarry wrote:
> Hi Stephen,
>
> With all the kind help from you and Justin, I finally made the latest
> refpolicy-2.20091117 boot up successfully! Hat off for you two :-)
>
> Please see my embedded replies, thanks!
>
>
cool!! now what exactly did you have to do?
plase share!!
Justin P. Mattock
> Date: Tue, 26 Jan 2010 01:17:49 -0800
> From: justinmattock at gmail.com
> To: harrytaurus2002 at hotmail.com
> CC: sds at tycho.nsa.gov; refpolicy at oss1.tresys.com; selinux at tycho.nsa.gov
> Subject: Re: [refpolicy] Bootup problem with refpolicy-2.20091117 - 4:login successfully finally!
>
> On 01/26/10 00:50, TaurusHarry wrote:
> > Hi Stephen,
> >
> > With all the kind help from you and Justin, I finally made the latest
> > refpolicy-2.20091117 boot up successfully! Hat off for you two :-)
> >
> > Please see my embedded replies, thanks!
> >
> >
>
> cool!! now what exactly did you have to do?
>
> plase share!!
>
> Justin P. Mattock
Hi Justin,
Please refer to the end of my previous email, I have put my summary for this problem there :-)
I really appreciate all your kind help and suggestions!
Best regards,
Harry
_________________________________________________________________
?Windows Live ???????Messenger2009????
http://www.windowslive.cn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100126/31b2ae0f/attachment.html
On 01/26/2010 09:50 AM, TaurusHarry wrote:
>
> Hi Stephen,
>
> With all the kind help from you and Justin, I finally made the latest refpolicy-2.20091117 boot up successfully! Hat off for you two :-)
>
> Please see my embedded replies, thanks!
>
>> Subject: RE: [refpolicy] Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken
>> From: sds at tycho.nsa.gov
>> To: harrytaurus2002 at hotmail.com
>> CC: refpolicy at oss1.tresys.com; selinux at tycho.nsa.gov
>> Date: Mon, 25 Jan 2010 10:35:45 -0500
>>
>> On Mon, 2010-01-25 at 09:32 +0000, TaurusHarry wrote:
>>> 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
>>
>> Hmm..so you don't have secmark enabled by default? Kernel config?
>
> $ grep SECMARK linux-sun_cp3020-cgl-build/.config
> CONFIG_NETWORK_SECMARK=y
> # CONFIG_NETFILTER_XT_TARGET_SECMARK is not set
> $
>
> More secmark options should I enable?
>
>>
>>> 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.
>>
>> Rebuild policy with dontaudits removed (semodule -DB) and retry, then
>> look for audit messages involving getty.
>
> Yeah, I created a policy store and then do semodule -DB and reboot, I found AVC denied messages about domains of sendmail_t, hostname_t, quota_t, dmesg_t lack the read privilege against console_device_t, which is expected because we have called term_dontaudit_use_console() interface for these domains.
>
> Since so far we have identified that my problem is rooted with getty_t, so I went on to take a quick glance at getty.te and very suprisingly found this dontaudit interface has been called for getty_t too! For me I am trying to login my target through a serial console, rather than any tty device, so I assume the getty_t should be granted all necessary privileges to operate the console. Once I removed the term_dontaudit_use_console(getty_t) I could find following AVC denied message:
>
>
>
>
>
>
>
>
>
> type=1400
> audit(1264520547.936:68): avc: denied { noatsecure } for pid=2292
> comm="login"
> scontext=system_u:system_r:getty_t:s0-s15:c0.c255
> tcontext=system_u:system_r:local_login_t:s0-s15:c0.c255
> tclass=process
I had similar issue with prelink_system_cron policy, where it required
noatsecure.
Please consider filing a bug report with regard to the
term_use_console(getty_t)
>
> which I guess is right the root cause to my problem. Once I replaced it by term_use_console(getty_t), I finally could login successfully!
>
> This problem made me sleepless for like 10 days and I would like to take this opportunity to summarize it here:
> 1. use enforcing=0 bootparam if unable to login selinux, then dmesg all those AVC denied messages for potential extra TE rules;
> 2. problem could be caused by files not being properly labeled, as well as necessary TE rules are missing. In my case many domains has no search right against tmpfs_t, however, tmpfs_t doesn't exist even in file_contexts, this indicates tmpfs filesystem has not been properly labeled. It turns out start_udev should have labeled tmpfs once it mounts tmpfs on /dev;
> 3, if perblem persists but no relevant AVC denied messsage could be referenced, use semodule -DB to rebuild policy and remove all those dontaudit rules, or remove the call to some dontaudit interface in the related .te, so thar SELinux could throw out as many AVC denied messages as possible.
>
> Next, I will go on play with the latest refpolicy package and bring up the extra necessary TE rules I find.
>
> Thank you so very much, again!
>
> Best regards,
> Harry
>
>
>>
>> --
>> 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 at tycho.nsa.gov with
>> the words "unsubscribe selinux" without quotes as the message.
>
> _________________________________________________________________
> ?Windows Live ???????Messenger2009????
> http://www.windowslive.cn
>
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100126/bb6b171b/attachment.bin
Hi Dom,
Thanks for you suggestion! Do you know where I can file a bug report for the refpolicy package?
Thanks,
Harry
_________________________________________________________________
?????????????????msn?????
http://ditu.live.com/?form=TL&swm=1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100126/cbf89a39/attachment.html
On Tue, 2010-01-26 at 08:50 +0000, TaurusHarry wrote:
> Hi Stephen,
>
> With all the kind help from you and Justin, I finally made the latest
> refpolicy-2.20091117 boot up successfully! Hat off for you two :-)
>
> Please see my embedded replies, thanks!
>
> > Subject: RE: [refpolicy] Bootup problem with refpolicy-2.20091117 -
> 3: MAKEDEV ok but /var/lock/subsys/ broken
> > From: sds at tycho.nsa.gov
> > To: harrytaurus2002 at hotmail.com
> > CC: refpolicy at oss1.tresys.com; selinux at tycho.nsa.gov
> > Date: Mon, 25 Jan 2010 10:35:45 -0500
> >
> > On Mon, 2010-01-25 at 09:32 +0000, TaurusHarry wrote:
> > > 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
> >
> > Hmm..so you don't have secmark enabled by default? Kernel config?
>
> $ grep SECMARK linux-sun_cp3020-cgl-build/.config
> CONFIG_NETWORK_SECMARK=y
> # CONFIG_NETFILTER_XT_TARGET_SECMARK is not set
> $
>
> More secmark options should I enable?
If you are still using a kernel < 2.6.29, then you also want:
SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y
--
Stephen Smalley
National Security Agency
On 01/26/2010 02:16 PM, TaurusHarry wrote:
>
> Hi Dom,
>
>
>
> Thanks for you suggestion! Do you know where I can file a bug report for the refpolicy package?
I guess you could create a patch to refpolicy git and post it here. With
a recognizable subject.
or, not sure about this, try:
http://oss.tresys.com/projects/refpolicy/report/1
>
> Thanks,
>
> Harry
>
> _________________________________________________________________
> ?????????????????msn?????
> http://ditu.live.com/?form=TL&swm=1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100126/4fb8f760/attachment.bin
>> More secmark options should I enable?
>
> If you are still using a kernel< 2.6.29, then you also want:
> SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y
>
what does his inittab look like?
had some funk issue with min,
policy worked after adjusting inittab
(maybe this is something with mgetty);
Justin P. Mattock