Hi all,
On my sandbox if polyinstantiation is enabled then user's HOME will be created in /home/home.inst/ (the instance directory) and mounted to /home/[user] (the base directory). The namespace.conf is quoted below:
[root/sysadm_r/s0 at localhost ~]# cat /etc/security/namespace.conf
...
/tmp /tmp-inst/ level root,adm
/var/tmp /var/tmp-inst/ level root,adm
$HOME /home/home.inst/ level root,adm
[root/sysadm_r/s0 at localhost ~]#
[root/sysadm_r/s0 at localhost ~]# matchpathcon /home/
/home system_u:object_r:home_root_t:s0-s15:c0.c1023
[root/sysadm_r/s0 at localhost ~]# matchpathcon /home/home.inst
/home/home.inst system_u:object_r:tmp_t:s0
[root/sysadm_r/s0 at localhost ~]# matchpathcon /home/home.inst/something
/home/home.inst/something user_u:object_r:user_home_t:s0
[root/sysadm_r/s0 at localhost ~]#
As we can see, the instance directory will be labeled as user_home_t, rather than user_home_dir_t as the base directory.
Is this correct? if not, how could I properly define the label of the instance directory to be the same as that of the base directory?
If yes, then I am afraid applications would have to be granted the user_home_t:dir search permissions at least along with the search permission on user_home_dir_t. The attached patch contains an example for [user]_screen_t.
Thanks a lot!
Best regards,
Harry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110211/c5132dd6/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-fix-userdom_user_home_domtrans.patch
Type: text/x-patch
Size: 1161 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110211/c5132dd6/attachment.bin
On 02/10/11 22:33, HarryCiao wrote:
> Hi all,
>
> On my sandbox if polyinstantiation is enabled then user's HOME will be
> created in /home/home.inst/ (the instance directory) and mounted to
> /home/[user] (the base directory). The namespace.conf is quoted below:
>
> [root/sysadm_r/s0 at localhost ~]# cat /etc/security/namespace.conf
> ...
> /tmp /tmp-inst/ level root,adm
> /var/tmp /var/tmp-inst/ level root,adm
> $HOME /home/home.inst/ level root,adm
> [root/sysadm_r/s0 at localhost ~]#
>
> [root/sysadm_r/s0 at localhost ~]# matchpathcon /home/
> /home system_u:object_r:home_root_t:s0-s15:c0.c1023
> [root/sysadm_r/s0 at localhost ~]# matchpathcon /home/home.inst
> /home/home.inst system_u:object_r:tmp_t:s0
> [root/sysadm_r/s0 at localhost ~]# matchpathcon /home/home.inst/something
> /home/home.inst/something user_u:object_r:user_home_t:s0
> [root/sysadm_r/s0 at localhost ~]#
>
>
> As we can see, the instance directory will be labeled as user_home_t,
> rather than user_home_dir_t as the base directory.
>
> Is this correct? if not, how could I properly define the label of the
> instance directory to be the same as that of the base directory?
>
> If yes, then I am afraid applications would have to be granted the
> user_home_t:dir search permissions at least along with the search
> permission on user_home_dir_t. The attached patch contains an example
> for [user]_screen_t.
> Thanks a lot!
Its not the desired behavior, in my opinion. The labeling should be the
same as if there were no polyinstantiation. Someone more familiar with
how the polyinstantiation is set up with pam_namespace will have to
comment further. Its probably more appropriate to discuss this on the
SELinux list.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com