Hello,
libmagic (better known by its CLI frontend 'file') needs to mmap() its
signature database, which is currently labeled usr_t. If any of
refpolicy's application domains need to call 'file' (or use libmagic)
directly, we may want to create a new domain for this signature db so
that the map permission can be granted only on this domain instead of
the much bigger usr_t.
However, the only domains I've found so far which need this access are
sysadm_t/staff_t/user_t and portage_t. The user domains already have the
neccessary permission, leaving only portage_t. Given that portage_t can
access *all* files in any case, I've decided to keep the policy simple
by just allowing it to map usr_t.
Is anyone aware of other file/libmagic users which would warrant the
creation of a new domain for the signature db?
Regards,
Luis Ressel
This is needed for eselect, which portage automatically invokes in some
situations.
---
portage.te | 2 ++
1 file changed, 2 insertions(+)
diff --git a/portage.te b/portage.te
index 3b28f81..269329b 100644
--- a/portage.te
+++ b/portage.te
@@ -186,6 +186,8 @@ domain_dontaudit_read_all_domains_state(portage_t)
# modify any files in the system
files_manage_all_files(portage_t)
+# eselect uses file, which mmap()s its db
+files_map_usr(portage_t)
selinux_get_fs_mount(portage_t)
--
2.14.1
On Tue, Sep 19, 2017 at 06:40:20PM +0200, Luis Ressel via refpolicy wrote:
> Hello,
>
> libmagic (better known by its CLI frontend 'file') needs to mmap() its
> signature database, which is currently labeled usr_t. If any of
> refpolicy's application domains need to call 'file' (or use libmagic)
> directly, we may want to create a new domain for this signature db so
> that the map permission can be granted only on this domain instead of
> the much bigger usr_t.
>
> However, the only domains I've found so far which need this access are
> sysadm_t/staff_t/user_t and portage_t. The user domains already have the
> neccessary permission, leaving only portage_t. Given that portage_t can
> access *all* files in any case, I've decided to keep the policy simple
> by just allowing it to map usr_t.
>
> Is anyone aware of other file/libmagic users which would warrant the
> creation of a new domain for the signature db?
Stuff like icons probably also need to be mapped and are also usr_t, so i don't think that confining that by itself will solve all the issues
>
> Regards,
> Luis Ressel
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170919/2aca0e1d/attachment.bin
On Tue, 19 Sep 2017 18:38:22 +0200
Dominick Grift via refpolicy <[email protected]> wrote:
> On Tue, Sep 19, 2017 at 06:40:20PM +0200, Luis Ressel via refpolicy
> wrote:
> > Hello,
> >
> > libmagic (better known by its CLI frontend 'file') needs to mmap()
> > its signature database, which is currently labeled usr_t. If any of
> > refpolicy's application domains need to call 'file' (or use
> > libmagic) directly, we may want to create a new domain for this
> > signature db so that the map permission can be granted only on this
> > domain instead of the much bigger usr_t.
> >
> > However, the only domains I've found so far which need this access
> > are sysadm_t/staff_t/user_t and portage_t. The user domains already
> > have the neccessary permission, leaving only portage_t. Given that
> > portage_t can access *all* files in any case, I've decided to keep
> > the policy simple by just allowing it to map usr_t.
> >
> > Is anyone aware of other file/libmagic users which would warrant the
> > creation of a new domain for the signature db?
>
> Stuff like icons probably also need to be mapped and are also usr_t,
> so i don't think that confining that by itself will solve all the
> issues
Yes, the GTK icon cache is also labeled usr_t and needs to be mappable.
However, compared to magic.mgc there are more domains which will need
this access, so I'm planning to create a new domain.
If I don't run into any problems, I'll submit a patch after dinner.
Cheers,
Luis Ressel
On 09/19/2017 02:36 PM, Luis Ressel via refpolicy wrote:
> On Tue, 19 Sep 2017 18:38:22 +0200
> Dominick Grift via refpolicy <[email protected]> wrote:
>
>> On Tue, Sep 19, 2017 at 06:40:20PM +0200, Luis Ressel via refpolicy
>> wrote:
>>> Hello,
>>>
>>> libmagic (better known by its CLI frontend 'file') needs to mmap()
>>> its signature database, which is currently labeled usr_t. If any of
>>> refpolicy's application domains need to call 'file' (or use
>>> libmagic) directly, we may want to create a new domain for this
>>> signature db so that the map permission can be granted only on this
>>> domain instead of the much bigger usr_t.
>>>
>>> However, the only domains I've found so far which need this access
>>> are sysadm_t/staff_t/user_t and portage_t. The user domains already
>>> have the neccessary permission, leaving only portage_t. Given that
>>> portage_t can access *all* files in any case, I've decided to keep
>>> the policy simple by just allowing it to map usr_t.
>>>
>>> Is anyone aware of other file/libmagic users which would warrant the
>>> creation of a new domain for the signature db?
>>
>> Stuff like icons probably also need to be mapped and are also usr_t,
>> so i don't think that confining that by itself will solve all the
>> issues
>
> Yes, the GTK icon cache is also labeled usr_t and needs to be mappable.
> However, compared to magic.mgc there are more domains which will need
> this access, so I'm planning to create a new domain.
>
> If I don't run into any problems, I'll submit a patch after dinner.
I'm not really concerned about mapping usr_t, as it is generally not
writeable.
--
Chris PeBenito
On 09/19/2017 12:40 PM, Luis Ressel via refpolicy wrote:
> This is needed for eselect, which portage automatically invokes in some
> situations.
> ---
> portage.te | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/portage.te b/portage.te
> index 3b28f81..269329b 100644
> --- a/portage.te
> +++ b/portage.te
> @@ -186,6 +186,8 @@ domain_dontaudit_read_all_domains_state(portage_t)
>
> # modify any files in the system
> files_manage_all_files(portage_t)
> +# eselect uses file, which mmap()s its db
> +files_map_usr(portage_t)
>
> selinux_get_fs_mount(portage_t)
Merged, though it needed to be fixed to use the existing interface.
--
Chris PeBenito