[refpolicy] Granting kernel_t (kdevtmpfs) manage rights on /dev/* ?

[sven.vermeulen@siphos.be (Sven Vermeulen)]

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