Hi all
I was looking into what seemed to be a cosmetic denial, namely kdevtmpfs
trying to search through device nodes in /dev. Now, kdevtmpfs is *meant* to
manage/support the device nodes in /dev so I was leaning towards allowing
kernel_t (which is the domain kdevtmpfs runs as) manage rights on all
devices nodes:
dev_manage_all_dev_nodes(kernel_t)
This was also suggested back in November 2013 by Luis Ressel [1] but without
response. I tried to implement this locally first, and hit quite a few
hurdles.
First of all, dev_manage_all_dev_nodes(kernel_t) also assigns a number of
attributes to kernel_t which are not defined by a base module. That makes
that "make base" fails. The attributes are needed to have a set of
neverallow statements (in the storage module) remain valid (look for the
neverallow statements related to fixed_disk_raw_{read,write} to begin).
[1] http://oss.tresys.com/pipermail/refpolicy/2013-November/006614.html
At this point, I think I have three alternatives that would still allow me
to go forward with granting kernel_t the necessary rights:
- Explicitly mark kernel_t as exempt for the neverallow rules. This would
require the storage module to have a gen_require(`type kernel_t;') in it.
Although this requirement will be matched (kernel_t is provided by the
base module) it is not beautiful (breaking isolation design) and is more
of a quick fix to allow the rights while working on a better solution
- Move the attribute declaration and neverallow rules out of the storage
module and in another module that is part of base, such as devices. This
however will lead to quite some refactoring.
- Make the storage module become part of the base module
The latter seems to be the best approach (through editing storage.if and
adding the "<required...>" tag at the beginning). However, this would cause
issues with systems that currently have storage loaded as a module: new
policy loads will not remove the old storage module (only replace the
existing modules) which will lead to a failure (duplicate attribute
declaration). And given the migration from 2.3 to 2.4 userspace we also need
to deal with the different priorities at the same time (which might make the
solution worse).
I could also use a different approach, ignoring the denials right now (as
the denials do not seem to impact system behavior noticeably) but I believe
that is not going to last for ever (the behavior of and dependency upon
kdevtmpfs is strongly use-case driven and depends on the users' system and
hardware afaics).
Personally I prefer the refactoring but based on the assumption that the
amount of work involved is relatively manageable... which might be a wrong
assumption to take.
Wkr,
Sven Vermeulen
On Wed, Mar 04, 2015 at 09:16:14PM +0100, Sven Vermeulen wrote:
> Hi all
>
> I was looking into what seemed to be a cosmetic denial, namely kdevtmpfs
> trying to search through device nodes in /dev. Now, kdevtmpfs is *meant* to
> manage/support the device nodes in /dev so I was leaning towards allowing
> kernel_t (which is the domain kdevtmpfs runs as) manage rights on all
> devices nodes:
>
> dev_manage_all_dev_nodes(kernel_t)
>
> This was also suggested back in November 2013 by Luis Ressel [1] but without
> response. I tried to implement this locally first, and hit quite a few
> hurdles.
>
> First of all, dev_manage_all_dev_nodes(kernel_t) also assigns a number of
> attributes to kernel_t which are not defined by a base module. That makes
> that "make base" fails. The attributes are needed to have a set of
> neverallow statements (in the storage module) remain valid (look for the
> neverallow statements related to fixed_disk_raw_{read,write} to begin).
>
> [1] http://oss.tresys.com/pipermail/refpolicy/2013-November/006614.html
>
> At this point, I think I have three alternatives that would still allow me
> to go forward with granting kernel_t the necessary rights:
>
> - Explicitly mark kernel_t as exempt for the neverallow rules. This would
> require the storage module to have a gen_require(`type kernel_t;') in it.
> Although this requirement will be matched (kernel_t is provided by the
> base module) it is not beautiful (breaking isolation design) and is more
> of a quick fix to allow the rights while working on a better solution
> - Move the attribute declaration and neverallow rules out of the storage
> module and in another module that is part of base, such as devices. This
> however will lead to quite some refactoring.
> - Make the storage module become part of the base module
>
> The latter seems to be the best approach (through editing storage.if and
> adding the "<required...>" tag at the beginning). However, this would cause
> issues with systems that currently have storage loaded as a module: new
> policy loads will not remove the old storage module (only replace the
> existing modules) which will lead to a failure (duplicate attribute
> declaration). And given the migration from 2.3 to 2.4 userspace we also need
> to deal with the different priorities at the same time (which might make the
> solution worse).
>
> I could also use a different approach, ignoring the denials right now (as
> the denials do not seem to impact system behavior noticeably) but I believe
> that is not going to last for ever (the behavior of and dependency upon
> kdevtmpfs is strongly use-case driven and depends on the users' system and
> hardware afaics).
>
> Personally I prefer the refactoring but based on the assumption that the
> amount of work involved is relatively manageable... which might be a wrong
> assumption to take.
As a temporary solution move storage to base. It probably is not realistically optional in refpolicy anyway (cause refpolicy cannot be built without userdomain module and that pretty much implies storage or does it not?).
In the meantime port reference policy to CIL. Where these limitations do not exist.
No, but yes, really this is what i would prefer. You already knew.
CIL is not ready for prime time yet though.
>
> Wkr,
> Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
02DFF788
4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20150304/0f9ab231/attachment.bin