Hi all,
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.
2, if log in the root user through 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.
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 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/:
root at d610-2:/root> id -Z
root:sysadm_r:sysadm_t:s0-s15:c0.c255
root at d610-2:/root> newrole -r secadm_r
Password:
bash: /root/.profile: Permission denied
root at d610-2:~# id -Z
root:secadm_r:secadm_t:s0-s15:c0.c255
root at d610-2:~# touch 1
touch: cannot touch `1': Permission denied
root at d610-2:~#
Shouldn't secadm_t and auditadm_t also have enough rights to the /root/ directory?
Any comments to above thress questions are greatly appreciated!
Best regards,
Harry
_________________________________________________________________
????? Windows Live ?????????????
http://www.microsoft.com/china/windows/windowslive/products/photo-gallery-edit.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090806/47dd71d4/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-mount-rw-etc-locks.patch
Type: text/x-diff
Size: 805 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090806/47dd71d4/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-newrole-relabel-console.patch
Type: text/x-diff
Size: 1567 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090806/47dd71d4/attachment-0001.bin
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
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
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
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