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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx
> To: harrytaurus2002@xxxxxxxxxxx
> CC: justinmattock@xxxxxxxxx; selinux@xxxxxxxxxxxxx; refpolicy@xxxxxxxxxxxxxxx
> 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
> > desir! able 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)
> >
&g! 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 befor e moving on to the MLS type.
> >
> > Any comment is greatly appreciated!
>
> refpolicy questions go to refpolicy@xxxxxxxxxxxxxx (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 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?

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


使用Messenger保护盾2.0,支持多账号登录! 现在就下载!

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux