From: harrytaurus2002@hotmail.com (TaurusHarry) Date: Fri, 7 Aug 2009 02:45:34 +0000 Subject: [refpolicy] Questions about TE rules in refpolicy-20081210 In-Reply-To: <1249567221.3000.46.camel@gorn.columbia.tresys.com> References: <1249567221.3000.46.camel@gorn.columbia.tresys.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hi Chris, Please see my embedded reply, thanks! > Subject: Re: [refpolicy] Questions about TE rules in refpolicy-20081210 > From: cpebenito at tresys.com > To: harrytaurus2002 at hotmail.com > CC: refpolicy at oss.tresys.com > Date: Thu, 6 Aug 2009 14:00:21 +0000 > > 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 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. > Thanks, and how could I fix this genhomedircon problem? > > 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. > 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? Best regards, Harry > -- > Chris PeBenito > Tresys Technology, LLC > (410) 290-1411 x150 > _________________________________________________________________ ??????????????? http://www.microsoft.com/china/windows/windowslive/products/photos-share.aspx?tab=1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090807/ce705c6d/attachment.html