From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Fri, 07 Aug 2009 09:10:33 -0400 Subject: [refpolicy] Questions about TE rules in refpolicy-20081210 In-Reply-To: References: <1249567221.3000.46.camel@gorn.columbia.tresys.com> Message-ID: <1249650633.1167.77.camel@gorn.columbia.tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Fri, 2009-08-07 at 02:45 +0000, TaurusHarry wrote: > > On Thu, 2009-08-06 at 02:56 +0000, TaurusHarry wrote: > > > I have several questions about some TE rules in the > > > refpolicy-20081210, when I am playing with it with MLS enabled, I run > > > into several issues and I am not clear if they are deliberately to be > > > designed to be this way or they might be potential problems, I > > > certainly don't want to open any security holes so I would very much > > > like to post my questions and patches to the mailing list for > > > comments. > > > > > > 1, after log in, if I do "mount" then it will display nothing, neither > > > "cat /etc/mtab" would show anything; > > > I glanced at mount.te, files_manage_etc_runtime_files() has already > > > been called for the mount_t, however, I think we have to call > > > files_manage_generic_locks() too, since the mount program needs to > > > grab some lock of /var/lock/mtab~ when writing into /etc/mtab. > > > Otherwise, there would be error messages like "Can't create lock > > > file /var/lock/mtab~2093: Permission denied(use -n flag to override)" > > > during kernel bootup. > > > > Which distribution is this? I believe the lock file is > > usually /etc/mtab~. My inspection of the mount code seems to confirm > > this too. > > > > Well, the mount version I am using is: mount (util-linux-ng 2.13.1) > I think you are right and will try to inspect into the code myself. > > > > 2, if log in the root user throug h serial console which is mapped > > > with the system console(/dev/console), I wou l d be unable to assume > > > another administrator roles(auditadm_r, secadm_r) by the newrole > > > program on top of the system console, the error message says that > > > newrole is unable to relabel the /dev/console device. > > > > > > I guess we not only need to append console_device_t to securetty_types > > > file but also grant newrole_t permission to relabeto and relabelfrom > > > the system console. > > > > I can reevaluate the patch from Fedora which should handle this, I > > believe. > > > > > 3, The /root/ directory is used to be labeled as "sysadm_home_t" or > > > "sysadm_home_dir_t", but I found them are labeled as "default_t" now > > > > Sound like there could be some problems with your genhomedircon. > > Thanks, and how could I fix this genhomedircon problem? Make sure /root is the home dir for root in /etc/passwd, to start. If not, retry one your selinux userspace toolchain issues are sorted out and you can use the current release. You can work around it by adding the explicit labeling rules. In addition, in 2.20081210, /root is user_home_dir_t. > > > and it seems that only the sysadm_t has read permission to the /root/ > > > di r ectory. If I assume another administrator role such as secadm_r, > > > then secadm_t would have trouble to read or write /root/: > > [...] > > > Shouldn't secadm_t and auditadm_t also have enough rights to > > > the /root/ directory? > > > > The rules aren't there in upstream refpolicy. > > > > We used to have interfaces for accessing /root such as > sysadm_read_home_content_files(), so you are saying such interfaces > still exist but not there in the upstream refpolicy? My mistake; if your /root is default_t only sysadm_t can access it. Also, sysadm_read_home_content_files() doesn't exist in 2.xxxxxxxx policies because of the new UBAC usage. You'd use userdom_read_user_home_content_files() -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150