I encountered this requirement when using poly-instantiation:
denied { relabelfrom } for pid=14189 comm="sshd" name="system_u:object_r:tmp_t:s0_domg472" dev=dm-3 ino=2884342 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
Athough in refpolicy sshd_t does not call userdom_tmp_role (Makes me wonder how refpolicy deals with poly-instantiation.
Nonetheless, to me it seems to make sense that if one give access to manage a type, you may also want to give relabel perms.
Oh, and it is untested (but i commited this to my branch and i will test it when i build a new version)
Signed-off-by: Dominick Grift <[email protected]>
---
:100644 100644 42d4e8d... 72203a0... M policy/modules/system/userdomain.if
policy/modules/system/userdomain.if | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
index 42d4e8d..72203a0 100644
--- a/policy/modules/system/userdomain.if
+++ b/policy/modules/system/userdomain.if
@@ -303,6 +303,12 @@ interface(`userdom_manage_tmp_role',`
manage_sock_files_pattern($2, user_tmp_t, user_tmp_t)
manage_fifo_files_pattern($2, user_tmp_t, user_tmp_t)
files_tmp_filetrans($2, user_tmp_t, { dir file lnk_file sock_file fifo_file })
+
+ relabel_dirs_pattern($2, user_tmp_t, user_tmp_t)
+ relabel_files_pattern($2, user_tmp_t, user_tmp_t)
+ relabel_lnk_files_pattern($2, user_tmp_t, user_tmp_t)
+ relabel_sock_files_pattern($2, user_tmp_t, user_tmp_t)
+ relabel_fifo_files_pattern($2, user_tmp_t, user_tmp_t)
')
#######################################
--
1.7.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100706/d8fa78f7/attachment-0001.bin
On 07/06/10 10:31, Dominick Grift wrote:
> I encountered this requirement when using poly-instantiation:
>
> denied { relabelfrom } for pid=14189 comm="sshd" name="system_u:object_r:tmp_t:s0_domg472" dev=dm-3 ino=2884342 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
>
> Athough in refpolicy sshd_t does not call userdom_tmp_role (Makes me wonder how refpolicy deals with poly-instantiation.
Not sure what you mean here, but sshd_t should never be calling
userdom_tmp_role(). That interface is only for building user roles/user
domains.
> Nonetheless, to me it seems to make sense that if one give access to manage a type, you may also want to give relabel perms.
NAK Relabeling is special. There are a few exceptions, but it should
almost always be separate from manage permissions.
> Oh, and it is untested (but i commited this to my branch and i will test it when i build a new version)
>
> Signed-off-by: Dominick Grift<[email protected]>
> ---
> :100644 100644 42d4e8d... 72203a0... M policy/modules/system/userdomain.if
> policy/modules/system/userdomain.if | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
> index 42d4e8d..72203a0 100644
> --- a/policy/modules/system/userdomain.if
> +++ b/policy/modules/system/userdomain.if
> @@ -303,6 +303,12 @@ interface(`userdom_manage_tmp_role',`
> manage_sock_files_pattern($2, user_tmp_t, user_tmp_t)
> manage_fifo_files_pattern($2, user_tmp_t, user_tmp_t)
> files_tmp_filetrans($2, user_tmp_t, { dir file lnk_file sock_file fifo_file })
> +
> + relabel_dirs_pattern($2, user_tmp_t, user_tmp_t)
> + relabel_files_pattern($2, user_tmp_t, user_tmp_t)
> + relabel_lnk_files_pattern($2, user_tmp_t, user_tmp_t)
> + relabel_sock_files_pattern($2, user_tmp_t, user_tmp_t)
> + relabel_fifo_files_pattern($2, user_tmp_t, user_tmp_t)
> ')
>
> #######################################
>
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Tue, Jul 06, 2010 at 12:08:25PM -0400, Christopher J. PeBenito wrote:
> On 07/06/10 10:31, Dominick Grift wrote:
> >I encountered this requirement when using poly-instantiation:
> >
> >denied { relabelfrom } for pid=14189 comm="sshd" name="system_u:object_r:tmp_t:s0_domg472" dev=dm-3 ino=2884342 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
> >
> >Athough in refpolicy sshd_t does not call userdom_tmp_role (Makes me wonder how refpolicy deals with poly-instantiation.
>
> Not sure what you mean here, but sshd_t should never be calling
> userdom_tmp_role(). That interface is only for building user
> roles/user domains.
pulseaudio.if: pulseaudio_role:
userdom_manage_home_role($1, pulseaudio_t)
userdom_manage_tmp_role($1, pulseaudio_t)
userdom_manage_tmpfs_role($1, pulseaudio_t)
wm.if: wm_role:
userdom_manage_home_role($2, $1_wm_t)
userdom_manage_tmpfs_role($2, $1_wm_t)
userdom_manage_tmp_role($2, $1_wm_t)
etc
>
> >Nonetheless, to me it seems to make sense that if one give access to manage a type, you may also want to give relabel perms.
>
> NAK Relabeling is special. There are a few exceptions, but it
> should almost always be separate from manage permissions.
>
> >Oh, and it is untested (but i commited this to my branch and i will test it when i build a new version)
> >
> >Signed-off-by: Dominick Grift<[email protected]>
> >---
> >:100644 100644 42d4e8d... 72203a0... M policy/modules/system/userdomain.if
> > policy/modules/system/userdomain.if | 6 ++++++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> >diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
> >index 42d4e8d..72203a0 100644
> >--- a/policy/modules/system/userdomain.if
> >+++ b/policy/modules/system/userdomain.if
> >@@ -303,6 +303,12 @@ interface(`userdom_manage_tmp_role',`
> > manage_sock_files_pattern($2, user_tmp_t, user_tmp_t)
> > manage_fifo_files_pattern($2, user_tmp_t, user_tmp_t)
> > files_tmp_filetrans($2, user_tmp_t, { dir file lnk_file sock_file fifo_file })
> >+
> >+ relabel_dirs_pattern($2, user_tmp_t, user_tmp_t)
> >+ relabel_files_pattern($2, user_tmp_t, user_tmp_t)
> >+ relabel_lnk_files_pattern($2, user_tmp_t, user_tmp_t)
> >+ relabel_sock_files_pattern($2, user_tmp_t, user_tmp_t)
> >+ relabel_fifo_files_pattern($2, user_tmp_t, user_tmp_t)
> > ')
> >
> > #######################################
> >
> >
> >
> >_______________________________________________
> >refpolicy mailing list
> >refpolicy at oss.tresys.com
> >http://oss.tresys.com/mailman/listinfo/refpolicy
>
>
> --
> Chris PeBenito
> Tresys Technology, LLC
> http://www.tresys.com | oss.tresys.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100706/367574ad/attachment.bin
On Tue, Jul 06, 2010 at 12:08:25PM -0400, Christopher J. PeBenito wrote:
> On 07/06/10 10:31, Dominick Grift wrote:
> >I encountered this requirement when using poly-instantiation:
> >
> >denied { relabelfrom } for pid=14189 comm="sshd" name="system_u:object_r:tmp_t:s0_domg472" dev=dm-3 ino=2884342 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
> >
> >Athough in refpolicy sshd_t does not call userdom_tmp_role (Makes me wonder how refpolicy deals with poly-instantiation.
>
> Not sure what you mean here, but sshd_t should never be calling
> userdom_tmp_role(). That interface is only for building user
> roles/user domains.
>
> >Nonetheless, to me it seems to make sense that if one give access to manage a type, you may also want to give relabel perms.
>
> NAK Relabeling is special. There are a few exceptions, but it
> should almost always be separate from manage permissions.
If that is so, then why are relabeling perms included with userdom_manage_home_role()? It does not appear consistent.
>
> >Oh, and it is untested (but i commited this to my branch and i will test it when i build a new version)
> >
> >Signed-off-by: Dominick Grift<[email protected]>
> >---
> >:100644 100644 42d4e8d... 72203a0... M policy/modules/system/userdomain.if
> > policy/modules/system/userdomain.if | 6 ++++++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> >diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
> >index 42d4e8d..72203a0 100644
> >--- a/policy/modules/system/userdomain.if
> >+++ b/policy/modules/system/userdomain.if
> >@@ -303,6 +303,12 @@ interface(`userdom_manage_tmp_role',`
> > manage_sock_files_pattern($2, user_tmp_t, user_tmp_t)
> > manage_fifo_files_pattern($2, user_tmp_t, user_tmp_t)
> > files_tmp_filetrans($2, user_tmp_t, { dir file lnk_file sock_file fifo_file })
> >+
> >+ relabel_dirs_pattern($2, user_tmp_t, user_tmp_t)
> >+ relabel_files_pattern($2, user_tmp_t, user_tmp_t)
> >+ relabel_lnk_files_pattern($2, user_tmp_t, user_tmp_t)
> >+ relabel_sock_files_pattern($2, user_tmp_t, user_tmp_t)
> >+ relabel_fifo_files_pattern($2, user_tmp_t, user_tmp_t)
> > ')
> >
> > #######################################
> >
> >
> >
> >_______________________________________________
> >refpolicy mailing list
> >refpolicy at oss.tresys.com
> >http://oss.tresys.com/mailman/listinfo/refpolicy
>
>
> --
> Chris PeBenito
> Tresys Technology, LLC
> http://www.tresys.com | oss.tresys.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100706/033188a2/attachment.bin
On 07/06/10 12:22, Dominick Grift wrote:
> On Tue, Jul 06, 2010 at 12:08:25PM -0400, Christopher J. PeBenito wrote:
>> On 07/06/10 10:31, Dominick Grift wrote:
>>> I encountered this requirement when using poly-instantiation:
>>>
>>> denied { relabelfrom } for pid=14189 comm="sshd" name="system_u:object_r:tmp_t:s0_domg472" dev=dm-3 ino=2884342 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
>>>
>>> Athough in refpolicy sshd_t does not call userdom_tmp_role (Makes me wonder how refpolicy deals with poly-instantiation.
>>
>> Not sure what you mean here, but sshd_t should never be calling
>> userdom_tmp_role(). That interface is only for building user
>> roles/user domains.
>
> pulseaudio.if: pulseaudio_role:
>
> userdom_manage_home_role($1, pulseaudio_t)
> userdom_manage_tmp_role($1, pulseaudio_t)
> userdom_manage_tmpfs_role($1, pulseaudio_t)
>
> wm.if: wm_role:
>
> userdom_manage_home_role($2, $1_wm_t)
> userdom_manage_tmpfs_role($2, $1_wm_t)
> userdom_manage_tmp_role($2, $1_wm_t)
>
> etc
I'm already working on removing these.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Tue, Jul 06, 2010 at 01:02:49PM -0400, Christopher J. PeBenito wrote:
> On 07/06/10 12:22, Dominick Grift wrote:
> >On Tue, Jul 06, 2010 at 12:08:25PM -0400, Christopher J. PeBenito wrote:
> >>On 07/06/10 10:31, Dominick Grift wrote:
> >>>I encountered this requirement when using poly-instantiation:
> >>>
> >>>denied { relabelfrom } for pid=14189 comm="sshd" name="system_u:object_r:tmp_t:s0_domg472" dev=dm-3 ino=2884342 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
> >>>
> >>>Athough in refpolicy sshd_t does not call userdom_tmp_role (Makes me wonder how refpolicy deals with poly-instantiation.
> >>
> >>Not sure what you mean here, but sshd_t should never be calling
> >>userdom_tmp_role(). That interface is only for building user
> >>roles/user domains.
> >
> >pulseaudio.if: pulseaudio_role:
> >
> > userdom_manage_home_role($1, pulseaudio_t)
> > userdom_manage_tmp_role($1, pulseaudio_t)
> > userdom_manage_tmpfs_role($1, pulseaudio_t)
> >
> >wm.if: wm_role:
> >
> > userdom_manage_home_role($2, $1_wm_t)
> > userdom_manage_tmpfs_role($2, $1_wm_t)
> > userdom_manage_tmp_role($2, $1_wm_t)
> >
> >etc
>
> I'm already working on removing these.
I am using a modified wm module that has these removed. You may want to see it. It is in my repository.
As for pulseaudio, removing it will break things and stop pa for functioning with SELinux.
>
> --
> Chris PeBenito
> Tresys Technology, LLC
> http://www.tresys.com | oss.tresys.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100706/9c700634/attachment.bin
On 07/06/10 13:06, Dominick Grift wrote:
> On Tue, Jul 06, 2010 at 01:02:49PM -0400, Christopher J. PeBenito wrote:
>> On 07/06/10 12:22, Dominick Grift wrote:
>>> On Tue, Jul 06, 2010 at 12:08:25PM -0400, Christopher J. PeBenito wrote:
>>>> On 07/06/10 10:31, Dominick Grift wrote:
>>>>> I encountered this requirement when using poly-instantiation:
>>>>>
>>>>> denied { relabelfrom } for pid=14189 comm="sshd" name="system_u:object_r:tmp_t:s0_domg472" dev=dm-3 ino=2884342 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
>>>>>
>>>>> Athough in refpolicy sshd_t does not call userdom_tmp_role (Makes me wonder how refpolicy deals with poly-instantiation.
>>>>
>>>> Not sure what you mean here, but sshd_t should never be calling
>>>> userdom_tmp_role(). That interface is only for building user
>>>> roles/user domains.
>>>
>>> pulseaudio.if: pulseaudio_role:
>>>
>>> userdom_manage_home_role($1, pulseaudio_t)
>>> userdom_manage_tmp_role($1, pulseaudio_t)
>>> userdom_manage_tmpfs_role($1, pulseaudio_t)
>>>
>>> wm.if: wm_role:
>>>
>>> userdom_manage_home_role($2, $1_wm_t)
>>> userdom_manage_tmpfs_role($2, $1_wm_t)
>>> userdom_manage_tmp_role($2, $1_wm_t)
>>>
>>> etc
>>
>> I'm already working on removing these.
>
> I am using a modified wm module that has these removed. You may want to see it. It is in my repository.
>
> As for pulseaudio, removing it will break things and stop pa for functioning with SELinux.
Well I'm not actually removing them, but replacing them.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com