From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Thu, 06 Aug 2009 14:00:21 +0000 Subject: [refpolicy] Questions about TE rules in refpolicy-20081210 In-Reply-To: References: Message-ID: <1249567221.3000.46.camel@gorn.columbia.tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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. > 2, if log in the root user throug h serial console which is mapped > with the system console(/dev/console), I would 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. > and it seems that only the sysadm_t has read permission to the /root/ > directory. 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. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150