From: harrytaurus2002@hotmail.com (TaurusHarry) Date: Mon, 10 Aug 2009 06:56:47 +0000 Subject: [refpolicy] Questions about TE rules in refpolicy-20081210 In-Reply-To: <1249650633.1167.77.camel@gorn.columbia.tresys.com> References: <1249567221.3000.46.camel@gorn.columbia.tresys.com> <1249650633.1167.77.camel@gorn.columbia.tresys.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hi Christopher, Many thanks for your good advices :) After I changed the security context of the /root directory by semanage fcontext or explicitly specify it in the userdomain.fc as +/root -d gen_context(system_u:object_r:user_home_dir_t,s0) +/root/.+ gen_context(system_u:object_r:user_home_t,s0) then its label will be changed from default_t to user_home_dir_t. Because both secadm_r and auditadm_r are created by the template of userdom_unpriv_user_template(), which in the end will call the userdom_manage_home_role() interface, secadm_r and auditadm_r are able to read/write the /root directory now. Thanks again! Best wishes, Harry > 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: Fri, 7 Aug 2009 09:10:33 -0400 > > 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 > _________________________________________________________________ ?Windows Live ??????????Messenger? http://www.windowslive.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090810/3b78783b/attachment.html