Bootup problem with refpolicy-2.20091117

Bootup problem with refpolicy-2.20091117

[TaurusHarry]

[-- Attachment #1: Type: text/plain, Size: 4513 bytes --]


Hi SELinux experts,

This is my very first time to try out the latest refpolicy-2.20091117 and I am unable to boot SELinux up normally, in the very end the console will hang with messages like:
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

Aside from this, there are some strange error messages like "Starting udev: MAKEDEV: mkdir: File exists" and some AVC denied messages (detailed log is appended at the last).

However, I could boot up SELinux with refpolicy-2.20081210 successfully, what I do is to first boot Linux kernel into a shell and load SELinux policy image then label the whole filesystem, second boot into /sbin/init as normal. The SELinux userspace tools I am using are:
libsepol-2.0.36
libselinux-2.0.79
libsemanage-2.0.31
policycoreutils-2.0.62
checkpolicy-2.0.19
sepolgen-1.0.16

The kernel I am using is 2.6.27, Stephen kindly pointed out a SELinux kernel bug six months ago when I had a problem to boot up refpolicy-2.20081210, which should be fixed by the commit of "SELinux: check open perms in dentry_open not inode_permission", or bypassed by diabling the open_perms in policy_capabilities. 

The same set of kernel and rootfs work well for refpolicy-2.20081210 but do not for refpolicy-2.20091117, I wonder what changes could make a difference? What should I have done in order to use the latest refpolicy-2.20091117? Any extra SELinux kernel commits I should port back to 2.6.27, or do I need to update SELinux userspace tools to the latest as well?

Any comment is greatly appreciated! Thank you very much for your help!

Best regards,
Harry

-----------
...
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 296k freed
type=1404 audit(1263731960.249:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
type=1403 audit(1263731961.676:3): policy loaded auid=4294967295 ses=4294967295
INIT: version 2.86 booting
type=1400 audit(1263731962.260:4): avc:  denied  { read } for  pid=960 comm="modprobe" name="console" dev=sda1 ino=244841 scontext=system_u:system_r:insmod_t:s0-s15:c0.c255 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file
type=1400 audit(1263731962.307:5): avc:  denied  { read } for  pid=960 comm="modprobe" path="/dev/console" dev=sda1 ino=244841 scontext=system_u:system_r:insmod_t:s0-s15:c0.c255 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file
Starting udev: MAKEDEV: mkdir: File exists
[  OK  ]
Setting hostname cp3020:  [  OK  ]
DM multipath kernel driver not loaded
No devices found
Checking filesystems
Checking all file systems.
[  OK  ]
can't create lock file /var/lock/mtab~2002: Permission denied (use -n flag to override)
Mounting local filesystems:  mount: sysfs already mounted or /sys busy
mount: devpts already mounted or /dev/pts busy
can't create lock file /var/lock/mtab~2007: Permission denied (use -n flag to override)
[FAILED]
Enabling local filesystem quotas:  [  OK  ]

*** Warning -- SELinux wr-strict policy relabel is required.
*** Relabeling could take a very long time, depending on file
*** system size and speed of hard drives.
Enabling /etc/fstab swaps:  [  OK  ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Starting enterprise event logger: [  OK  ]
Starting remote event logger: [  OK  ]
Starting syslog-ng: [FAILED]
Starting ipmi drivers: [  OK  ]
iscsid is stopped
iSCSI daemon not running.
Starting portmap: [  OK  ]
Mounting other filesystems:  mount: sysfs already mounted or /sys busy
mount: devpts already mounted or /dev/pts busy
can't create lock file /var/lock/mtab~2158: Permission denied (use -n flag to override)
[FAILED]
Starting sshd: [  OK  ]
Starting xinetd: [  OK  ]
Starting iSCSI daemon: [  OK  ]
[  OK  ]
Starting enterprise event log notification: [  OK  ]
Starting sendmail: [  OK  ]
Starting sm-client: /etc/rc3.d/S80sendmail: line 71: /sbin/restorecon: No such file or directory
[  OK  ]
Starting boa: [  OK  ]
Starting crond: [  OK  ]
Starting notification action daemon: [  OK  ]
Starting atd: [FAILED]
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
INIT: Id "0" respawning too fast: disabled for 5 minutes
INIT: Id "0" respawning too fast: disabled for 5 minutes
... 		 	   		  
_________________________________________________________________
MSN十周年庆典，查看MSN注册时间，赢取神秘大奖
http://10.msn.com.cn

[-- Attachment #2: Type: text/html, Size: 5199 bytes --]

Re: Bootup problem with refpolicy-2.20091117

[Justin P. Mattock]

On 01/17/10 18:40, TaurusHarry wrote:
> Hi SELinux experts,
> 
> This is my very first time to try out the latest refpolicy-2.20091117 
> and I am unable to boot SELinux up normally, in the very end the console 
> will hang with messages like:
> 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
> 
> Aside from this, there are some strange error messages like "Starting 
> udev: MAKEDEV: mkdir: File exists" and some AVC denied messages 
> (detailed log is appended at the last).
> 
> However, I could boot up SELinux with refpolicy-2.20081210 successfully, 
> what I do is to first boot Linux kernel into a shell and load SELinux 
> policy image then label the whole filesystem, second boot into 
> /sbin/init as normal. The SELinux userspace tools I am using are:
> libsepol-2.0.36
> libselinux-2.0.79
> libsemanage-2.0.31
> policycoreutils-2.0.62
> checkpolicy-2.0.19
> sepolgen-1.0.16
> 
> The kernel I am using is! 2.6.27, Stephen kindly pointed out a SELinux 
> kernel bug six months ago when I had a problem to boot up 
> refpolicy-2.20081210, which should be fixed by the commit of "SELinux: 
> check open perms in dentry_open not inode_permission", or bypassed by 
> diabling the open_perms in policy_capabilities.
> 
> The same set of kernel and rootfs work well for refpolicy-2.20081210 but 
> do not for refpolicy-2.20091117, I wonder what changes could make a 
> difference? What should I have done in order to use the latest 
> refpolicy-2.20091117? Any extra SELinux kernel commits I should port 
> back to 2.6.27, or do I need to update SELinux userspace tools to the 
> latest as well?
> 
> Any comment is greatly appreciated! Thank you very much for your help!
> 
> Best regards,
> Harry
> 
> -----------
> ...
> VFS: Mounted root (ext2 filesystem).
> Freeing unused kernel memory: 296k freed
> type=1404 audit(1263731960.249:2): enforcing=1 old_enforcing=0 
> auid=4294967295 ses=4294967295
> type=1403 ! audit(1263731961.676:3): policy loaded auid=4294967295 
> ses=4294967295< br>INIT: version 2.86 booting
> type=1400 audit(1263731962.260:4): avc: denied { read } for pid=960 
> comm="modprobe" name="console" dev=sda1 ino=244841 
> scontext=system_u:system_r:insmod_t:s0-s15:c0.c255 
> tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file
> type=1400 audit(1263731962.307:5): avc: denied { read } for pid=960 
> comm="modprobe" path="/dev/console" dev=sda1 ino=244841 
> scontext=system_u:system_r:insmod_t:s0-s15:c0.c255 
> tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file
> Starting udev: MAKEDEV: mkdir: File exists
> [ OK ]
> Setting hostname cp3020: [ OK ]
> DM multipath kernel driver not loaded
> No devices found
> Checking filesystems
> Checking all file systems.
> [ OK ]
> can't create lock file /var/lock/mtab~2002: Permission denied (use -n 
> flag to override)
> Mounting local filesystems: mount: sysfs already mounted or /sys busy
> mount: devpts a! lready mounted or /dev/pts busy
> can't create lock file /var/lock/mtab~2007: Permission denied (use -n 
> flag to override)
> [FAILED]
> Enabling local filesystem quotas: [ OK ]
> 
> *** Warning -- SELinux wr-strict policy relabel is required.
> *** Relabeling could take a very long time, depending on file
> *** system size and speed of hard drives.
> Enabling /etc/fstab swaps: [ OK ]
> INIT: Entering runlevel: 3
> Entering non-interactive startup
> Starting enterprise event logger: [ OK ]
> Starting remote event logger: [ OK ]
> Starting syslog-ng: [FAILED]
> Starting ipmi drivers: [ OK ]
> iscsid is stopped
> iSCSI daemon not running.
> Starting portmap: [ OK ]
> Mounting other filesystems: mount: sysfs already mounted or /sys busy
> mount: devpts already mounted or /dev/pts busy
> can't create lock file /var/lock/mtab~2158: Permission denied (use -n 
> flag to overrid! e)
> [FAILED]
> Starting sshd: [ OK ]
> Starting xinetd : [ OK ]
> Starting iSCSI daemon: [ OK ]
> [ OK ]
> Starting enterprise event log notification: [ OK ]
> Starting sendmail: [ OK ]
> Starting sm-client: /etc/rc3.d/S80sendmail: line 71: /sbin/restorecon: 
> No such file or directory
> [ OK ]
> Starting boa: [ OK ]
> Starting crond: [ OK ]
> Starting notification action daemon: [ OK ]
> Starting atd: [FAILED]
> 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
> INIT: Id "0" respawning too fast: disabled for 5 minutes
> INIT: Id "0" respawning too fast: disabled for 5 minutes
> ...
> ------------------------------------------------------------------------
> 使用Messenger保护盾2.0，支持多账号登录！ 现在就下载！ 
> <http://www.windowslive.cn/safe/>

hmm looking at the boot message the policy
is already loaded,but errors out with atd.
(or after)
and you have bootparams= selinux=1 enforcing=0
and /etc/selinux/config in permissive?

if both are set into permissive(the policy should load), then the
next best thing todo is a bisect(just grab the latest refpolicy from
git), this way you can get a better idea of whats causing this.

if you need help with doing a bisect let me know.

Justin P. Mattock

--
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.

RE: Bootup problem with refpolicy-2.20091117

[TaurusHarry]

[-- Attachment #1: Type: text/plain, Size: 6327 bytes --]




> Date: Sun, 17 Jan 2010 19:00:09 -0800
> From: justinmattock@gmail.com
> To: harrytaurus2002@hotmail.com
> CC: selinux@tycho.nsa.gov
> Subject: Re: Bootup problem with refpolicy-2.20091117
> 
> On 01/17/10 18:40, TaurusHarry wrote:
> > Hi SELinux experts,
> > 
> > This is my very first time to try out the latest refpolicy-2.20091117 
> > and I am unable to boot SELinux up normally, in the very end the console 
> > will hang with messages like:
> > 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
> > 
> > Aside from this, there are some strange error messages like "Starting 
> > udev: MAKEDEV: mkdir: File exists" and some AVC denied messages 
> > (detailed log is appended at the last).
> > 
> > However, I could boot up SELinux with refpolicy-2.20081210 successfully, 
> > what I do is to first boot Linux kernel into a shell and load SELinux 
> > policy image then label the whole filesystem, second boot into 
> > /sbin/init as normal. The SELinux userspace tools I am using are:
> > libsepol-2.0.36
> > libselinux-2.0.79
> > libsemanage-2.0.31
> > policycoreutils-2.0.62
> > checkpolicy-2.0.19
> > sepolgen-1.0.16
> > 
> > The kernel I am using is! 2.6.27, Stephen kindly pointed out a SELinux 
> > kernel bug six months ago when I had a problem to boot up 
> > refpolicy-2.20081210, which should be fixed by the commit of "SELinux: 
> > check open perms in dentry_open not inode_permission", or bypassed by 
> > diabling the open_perms in policy_capabilities.
> > 
> > The same set of kernel and rootfs work well for refpolicy-2.20081210 but 
> > do not for refpolicy-2.20091117, I wonder what changes could make a 
> > difference? What should I have done in order to use the latest 
> > refpolicy-2.20091117? Any extra SELinux kernel commits I should port 
> > back to 2.6.27, or do I need to update SELinux userspace tools to the 
> > latest as well?
> > 
> > Any comment is greatly appreciated! Thank you very much for your help!
> > 
> > Best regards,
> > Harry
> > 
> > -----------
> > ...
> > VFS: Mounted root (ext2 filesystem).
> > Freeing unused kernel memory: 296k freed
> > type=1404 audit(1263731960.249:2): enforcing=1 old_enforcing=0 
> > auid=4294967295 ses=4294967295
> > type=1403 ! audit(1263731961.676:3): policy loaded auid=4294967295 
> > ses=4294967295< br>INIT: version 2.86 booting
> > type=1400 audit(1263731962.260:4): avc: denied { read } for pid=960 
> > comm="modprobe" name="console" dev=sda1 ino=244841 
> > scontext=system_u:system_r:insmod_t:s0-s15:c0.c255 
> > tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file
> > type=1400 audit(1263731962.307:5): avc: denied { read } for pid=960 
> > comm="modprobe" path="/dev/console" dev=sda1 ino=244841 
> > scontext=system_u:system_r:insmod_t:s0-s15:c0.c255 
> > tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file
> > Starting udev: MAKEDEV: mkdir: File exists
> > [ OK ]
> > Setting hostname cp3020: [ OK ]
> > DM multipath kernel driver not loaded
> > No devices found
> > Checking filesystems
> > Checking all file systems.
> > [ OK ]
> > can't create lock file /var/lock/mtab~2002: Permission denied (use -n 
> > flag to override)
> > Mounting local filesystems: mount: sysfs already mounted or /sys busy
> > mount: devpts a! lready mounted or /dev/pts busy
> > can't create lock file /var/lock/mtab~2007: Permission denied (use -n 
> > flag to override)
> > [FAILED]
> > Enabling local filesystem quotas: [ OK ]
> > 
> > *** Warning -- SELinux wr-strict policy relabel is required.
> > *** Relabeling could take a very long time, depending on file
> > *** system size and speed of hard drives.
> > Enabling /etc/fstab swaps: [ OK ]
> > INIT: Entering runlevel: 3
> > Entering non-interactive startup
> > Starting enterprise event logger: [ OK ]
> > Starting remote event logger: [ OK ]
> > Starting syslog-ng: [FAILED]
> > Starting ipmi drivers: [ OK ]
> > iscsid is stopped
> > iSCSI daemon not running.
> > Starting portmap: [ OK ]
> > Mounting other filesystems: mount: sysfs already mounted or /sys busy
> > mount: devpts already mounted or /dev/pts busy
> > can't create lock file /var/lock/mtab~2158: Permission denied (use -n 
> > flag to overrid! e)
> > [FAILED]
> > Starting sshd: [ OK ]
> > Starting xinetd : [ OK ]
> > Starting iSCSI daemon: [ OK ]
> > [ OK ]
> > Starting enterprise event log notification: [ OK ]
> > Starting sendmail: [ OK ]
> > Starting sm-client: /etc/rc3.d/S80sendmail: line 71: /sbin/restorecon: 
> > No such file or directory
> > [ OK ]
> > Starting boa: [ OK ]
> > Starting crond: [ OK ]
> > Starting notification action daemon: [ OK ]
> > Starting atd: [FAILED]
> > 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
> > INIT: Id "0" respawning too fast: disabled for 5 minutes
> > INIT: Id "0" respawning too fast: disabled for 5 minutes
> > ...
> > ------------------------------------------------------------------------
> > 使用Messenger保护盾2.0，支持多账号登录！ 现在就下载！ 
> > <http://www.windowslive.cn/safe/>
> 
> hmm looking at the boot message the policy
> is already loaded,but errors out with atd.
> (or after)
> and you have bootparams= selinux=1 enforcing=0
> and /etc/selinux/config in permissive?
> 

Hi Justin,

Many thanks for your reply!

No, I'd just specified selinux=1 in kernel bootparams without enforcing=0, and the SELINUX=enforce in my /etc/selinux/config.


> if both are set into permissive(the policy should load), then the
> next best thing todo is a bisect(just grab the latest refpolicy from
> git), this way you can get a better idea of whats causing this.
> 
> if you need help with doing a bisect let me know.


Ok, I will go taste the latest refpolicy from git.

Thanks again!
Harry

> 
> Justin P. Mattock
> 
> --
> 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.
 		 	   		  
_________________________________________________________________
上Windows Live 中国首页，下载Messenger2009安全版！
http://www.windowslive.cn

[-- Attachment #2: Type: text/html, Size: 7790 bytes --]

Re: Bootup problem with refpolicy-2.20091117

[Justin P. Mattock]

o.k. so you have a bootparam as selinux=0,
and /etc/selinux/config > set to permissive right?


Justin P. Mattock

--
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.

RE: Bootup problem with refpolicy-2.20091117

[TaurusHarry]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]


HI Justin,

No, I have selinux=1 in the bootparam, and /etc/selinux/config set to enforce.

Thanks,
Harry


> Date: Mon, 18 Jan 2010 02:35:35 -0800
> From: justinmattock@gmail.com
> To: harrytaurus2002@hotmail.com
> CC: selinux@tycho.nsa.gov
> Subject: Re: Bootup problem with refpolicy-2.20091117
> 
> o.k. so you have a bootparam as selinux=0,
> and /etc/selinux/config > set to permissive right?
> 
> 
> Justin P. Mattock
> 
> --
> 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.
 		 	   		  
_________________________________________________________________
约会说不清地方？来试试微软地图最新msn互动功能！
http://ditu.live.com/?form=TL&swm=1

[-- Attachment #2: Type: text/html, Size: 1070 bytes --]

Re: Bootup problem with refpolicy-2.20091117

[Justin P. Mattock]

On 01/18/10 17:35, TaurusHarry wrote:
> HI Justin,
> 
> No, I have selinux=1 in the bootparam, and /etc/selinux/config set to 
> enforce.
> 
> Thanks,
> Harry
> 
> 
>  > Date: Mon, 18 Jan 2010 02:35:35 -0800
>  > From: justinmattock@gmail.com
>  > To: harrytaurus2002@hotmail.com
>  > CC: selinux@tycho.nsa.gov
>  > Subject: Re: Bootup problem with refpolicy-2.20091117
>  >
>  > o.k. so you have a bootparam as selinux=0,
>  > and /etc/selinux/config > set to permissive right?
>  >
>  >
>  > Justin P. Mattock
>  >
>  > --
>  > 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.
> 
> ------------------------------------------------------------------------
> 更多热辣资讯尽在新版MSN首页！ 立刻访问！ <http://cn.msn.com/>

then that could be what your hitting.
(noticed this a while back over here for some reason or another);

try booting with both: (boot param)enforcing=0
and (/etc/selinux/config)SELINUX=permissive

and see if you boot up.. then define the rules.

Justin P. Mattock

--
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.

RE: Bootup problem with refpolicy-2.20091117 - rules found but still can't login

[TaurusHarry]

[-- Attachment #1: Type: text/plain, Size: 3544 bytes --]


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_sockets(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 messages to SELinux rules as possible, however, even with all above additional 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!

Thanks a lot!
Harry


> Date: Mon, 18 Jan 2010 17:45:29 -0800
> From: justinmattock@gmail.com
> To: harrytaurus2002@hotmail.com
> CC: selinux@tycho.nsa.gov
> Subject: Re: Bootup problem with refpolicy-2.20091117
> 
 > then that could be what your hitting.
> (noticed this a while back over here for some reason or another);
> 
> try booting with both: (boot param)enforcing=0
> and (/etc/selinux/config)SELINUX=permissive
> 
> and see if you boot up.. then define the rules.
> 
> Justin P. Mattock
> 
> --
> 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.
 		 	   		  
_________________________________________________________________
约会说不清地方？来试试微软地图最新msn互动功能！
http://ditu.live.com/?form=TL&swm=1

[-- Attachment #2: Type: text/html, Size: 4066 bytes --]

Re: Bootup problem with refpolicy-2.20091117 - rules found but still can't login

[Justin P. Mattock]

On 01/21/10 01:36, 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.
>
(o.k. had to change the character encoding if you don't mind.)
first things first.. is obviously putting everything into permissive 
mode(boot param=enforcing=0,and /etc/selinux/config*
(which you seem to have done).

> 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)
>

alright so your using the stable release of refpolicy(apologize if any
typo's... a bit late,and a bit of hops in) ;-)

> +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_sockets(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)

I think the main thing first before customizations is making
sure everything is legit.(but could be wrong);
>
> (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?)
>

sounds like a problem with pam_namespace, and xselinux/xsandbox
(did dan think about polyinstantiation as he wrote xsandbox?(no offense))
noticed my home directory is being waxed out with a change of policy 
type(standard/mcs)

> I've tried my best to translate as many AVC denied messages to SELinux
> rules as possible, however, even with all above additional 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 :-(
>

with the namespace, and xsandbox thing I've set-up an new policy, 
relabeled with the new policy and for some reason have been stuck with
user_r:object_r:user_home_t(:s0) in my home dir(anything with name:name 
as the owner)
labeled in .mozilla/.thunderbird,and most of everything that was there
as the original home dir after compiling the policy(but could be my part 
because of keeping a copy of my home directory and copying over , 
because namespace/xsandbox keeps waxing out my home directory(or eating 
it up).

basically I see user_r:object_r:user_home_t(:s0) as the context even 
thoug I've defined my user name/login with semanage.
(but could be missing something);

> 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?
>

best thing is to pull everything from git
git clone http://oss.tresys.com/git/refpolicy.git
git clone http://oss.tresys.com/git/selinux.git

this way everybosy gets a better/updated idea of whats happening
(having policycoreutils 2yrs behind, libselinux might cause issues);

> 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.
>

I would stick with standard just to make things simple
mls does not work with the xserver(but could be wrong), mcs does, but 
just noticed a constraint with changing roles(but have not reported due 
to  making sure I have things legit);

> Any comment is greatly appreciated!
>
> Thanks a lot!
> Harry
>
>


first things first is making sure the policy loads.. so lets focus in
on that(people jump in anytime).

regards,

Justin P. Mattock

--
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.

RE: Bootup problem with refpolicy-2.20091117 - rules found but still can't login

[Stephen Smalley]

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@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


--
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.

[refpolicy] Bootup problem with refpolicy-2.20091117 - rules found but still can't login

[Stephen Smalley]

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

RE: Bootup problem with refpolicy-2.20091117 - rules found but still can't login

[TaurusHarry]

[-- Attachment #1: Type: text/plain, Size: 7559 bytes --]


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@tycho.nsa.gov
> To: harrytaurus2002@hotmail.com
> CC: justinmattock@gmail.com; selinux@tycho.nsa.gov; refpolicy@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@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@cp3020:/root> cat /proc/cmdline 
root=/dev/sda1 rw console=ttyS0,115200n8 ip=dhcp selinux=1 enforcing=0 BOOT_IMAGE=/vlm-boards/12885/qcao/kernel 
root@cp3020:/root> cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext2 rw,errors=continue 0 0
none /selinux selinuxfs rw 0 0
/proc /proc proc rw 0 0
/sys /sys sysfs rw 0 0
none /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
tmpfs /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
root@cp3020:/root> ls -Z /dev/ | grep tmpfs_t
lrwxrwxrwx  root root system_u:object_r:tmpfs_t:s0     MAKEDEV
drwxr-xr-x  root root system_u:object_r:tmpfs_t:s0     bsg
lrwxrwxrwx  root root system_u:object_r:tmpfs_t:s0     core
drwxr-xr-x  root root system_u:object_r:tmpfs_t:s0     cpu
drwxr-xr-x  root root system_u:object_r:tmpfs_t:s0     disk
lrwxrwxrwx  root root system_u:object_r:tmpfs_t:s0     fd
crw-------  root root system_u:object_r:tmpfs_t:s0     ipmi0
srw-rw-rw-  root root system_u:object_r:tmpfs_t:s15:c0.c255 log
drwxrwxrwt  root root system_u:object_r:tmpfs_t:s0     shm
lrwxrwxrwx  root root system_u:object_r:tmpfs_t:s0     stderr
lrwxrwxrwx  root root system_u:object_r:tmpfs_t:s0     stdin
lrwxrwxrwx  root root system_u:object_r:tmpfs_t:s0     stdout
root@cp3020:/root> /sbin/restorecon -R /dev
root@cp3020:/root> ls -Z /dev | grep tmpfs_t
root@cp3020:/root> ls -Z /dev | grep -v device_t
prw-------  root root system_u:object_r:initctl_t:s0   initctl
srw-rw-rw-  root root system_u:object_r:devlog_t:s0    log
crw-rw-rw-  root tty  system_u:object_r:ptmx_t:s0      ptmx
drwxr-xr-x  root root system_u:object_r:devpts_t:s0-s15:c0.c255 pts
crw-rw-rw-  root tty  system_u:object_r:devtty_t:s0    tty
root@cp3020:/root>

However, after reboot the console still hangs. I think many files under /dev/ are created by udev on-the-fly so we have to label them after creation. Then I modified rc.sysinit to move "/sbin/restorecon -R /dev" out of the 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@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
 		 	   		  
_________________________________________________________________
MSN十周年庆典，查看MSN注册时间，赢取神秘大奖
http://10.msn.com.cn

[-- Attachment #2: Type: text/html, Size: 9215 bytes --]

[refpolicy] Bootup problem with refpolicy-2.20091117 - rules found but still can't login

[TaurusHarry]

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 

Re: Bootup problem with refpolicy-2.20091117 - rules found but still can't login

[Justin P. Mattock]

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

--
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.

[refpolicy] Bootup problem with refpolicy-2.20091117 - rules found but still can't login

[Justin P. Mattock]

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

RE: Bootup problem with refpolicy-2.20091117 - rules found but still can't login

[Stephen Smalley]

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

The restorecon -R /dev has to be done on every boot since tmpfs is
ephemeral.

There are certain allow rules that are only included if DISTRO=redhat
related to relabeling of the tmpfs /dev I believe, as some other distros
took a different approach (mounting with rootcontext=?)?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] Bootup problem with refpolicy-2.20091117 - rules found but still can't login

[Stephen Smalley]

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

RE: Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken

[TaurusHarry]

[-- Attachment #1: Type: text/plain, Size: 7614 bytes --]


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@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@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@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

[-- Attachment #2: Type: text/html, Size: 12628 bytes --]

[refpolicy] Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken

[TaurusHarry]

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 

RE: [refpolicy] Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken

[TaurusHarry]

[-- Attachment #1: Type: text/plain, Size: 10396 bytes --]


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

[-- Attachment #2: Type: text/html, Size: 18721 bytes --]

[refpolicy] Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken

[TaurusHarry]

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 

RE: [refpolicy] Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken

[Stephen Smalley]

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@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.

Rebuild policy with dontaudits removed (semodule -DB) and retry, then
look for audit messages involving getty.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken

[Stephen Smalley]

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

RE: [refpolicy] Bootup problem with refpolicy-2.20091117 - 4:login successfully finally!

[TaurusHarry]

[-- Attachment #1: Type: text/plain, Size: 6162 bytes --]


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@tycho.nsa.gov
> To: harrytaurus2002@hotmail.com
> CC: refpolicy@oss1.tresys.com; selinux@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@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.
> 
> 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@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
 		 	   		  
_________________________________________________________________
上Windows Live 中国首页，下载Messenger2009安全版！
http://www.windowslive.cn

[-- Attachment #2: Type: text/html, Size: 7700 bytes --]

[refpolicy] Bootup problem with refpolicy-2.20091117 - 4:login successfully finally!

[TaurusHarry]

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 

Re: [refpolicy] Bootup problem with refpolicy-2.20091117 - 4:login successfully finally!

[Justin P. Mattock]

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

--
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.

[refpolicy] Bootup problem with refpolicy-2.20091117 - 4:login successfully finally!

[Justin P. Mattock]

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

RE: [refpolicy] Bootup problem with refpolicy-2.20091117 - 4:login successfully finally!

[TaurusHarry]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]




> Date: Tue, 26 Jan 2010 01:17:49 -0800
> From: justinmattock@gmail.com
> To: harrytaurus2002@hotmail.com
> CC: sds@tycho.nsa.gov; refpolicy@oss1.tresys.com; selinux@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

[-- Attachment #2: Type: text/html, Size: 1354 bytes --]

[refpolicy] Bootup problem with refpolicy-2.20091117 - 4:login successfully finally!

[TaurusHarry]

> 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 

[refpolicy] Bootup problem with refpolicy-2.20091117 - 4:login successfully finally!

[Dominick Grift]

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 

[refpolicy] Where could I file a bug report for refpolicy package

[TaurusHarry]

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 

[refpolicy] Where could I file a bug report for refpolicy package

[Dominick Grift]

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 

RE: [refpolicy] Bootup problem with refpolicy-2.20091117 - 4:login successfully finally!

[Stephen Smalley]

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@tycho.nsa.gov
> > To: harrytaurus2002@hotmail.com
> > CC: refpolicy@oss1.tresys.com; selinux@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


--
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.

[refpolicy] Bootup problem with refpolicy-2.20091117 - 4:login successfully finally!

[Stephen Smalley]

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

Re: [refpolicy] Bootup problem with refpolicy-2.20091117 - 4:login successfully finally!

[Justin P. Mattock]

>> 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

--
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.

[refpolicy] Bootup problem with refpolicy-2.20091117 - 4:login successfully finally!

[Justin P. Mattock]

>> 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