On 4/30/20 10:34 AM, Ondrej Mosnacek wrote:
On Thu, Apr 30, 2020 at 4:24 PM Chris PeBenito <pebenito@xxxxxxxx> wrote:
On 4/30/20 9:22 AM, Stephen Smalley wrote:
On Wed, Apr 29, 2020 at 3:01 PM James Carter <jwcart2@xxxxxxxxx> wrote:
I think the fact that the CIL, kernel to CIL, kernel to conf, and
module to CIL code is all in libsepol speaks to the fact of how
tightly integrated they are to the rest of libsepol. One argument that
could be made is that the policyrep stuff in setools really belongs in
libsepol.
Thinking about how libsepol could be encapsulated leads me to a couple
of possibilities. One way would be functions that could return lists
of rules. The policy module code gives us avrule_t, role_trans_rule_t,
role_allow_t, filename_trans_rule_t, range_trans_rule_t, and others.
Those structures are probably unlikely to change and, at least in this
case, creating a function that walks the filename_trans hashtable and
returns a list of filename_trans_rule_t certainly seems like it
wouldn't be too hard. Another possible way to encapsulate would be
create a way to walk the various hashtables element by element (I
think hashtab_map() requires too much knowledge of the internal
structures), returning an opaque structure to track where you are in
the hashtable and functions that allow you to get each part of the
rule being stored. There are other ways that it could be done, but I
could rewrite kernel to and module to stuff with either of those. CIL
itself would require some functions to insert rules into the policydb
which probably wouldn't be too hard. None of this would be too hard,
but it would take some time. The real question is would it really be
valuable?
I don't think we want to directly expose the existing data structures
from include/sepol/policydb/*.h (or at least not without a careful
audit) since those are often tightly coupled to policy compiler
internals and/or the kernel or module policy formats. Creating an
abstraction for each with a proper API in new definitions in
include/sepol/*.h would be preferable albeit more work. There was a
proposal a long time ago from the setools developers to create an
iterator interface and accessor functions for each data type, see
https://lore.kernel.org/selinux/200603212246.k2LMkRNq028071@xxxxxxxxxxxxxxxxxxxxxxxxxx/.
I agree. The hardest thing with writing the policyrep in setools was stuff like
the value_to_datum indirections, type_attr_map, etc. and knowing when to use
value vs value-1. An API that has a new set of structs would be ideal.
Unfortunately, since setools policyrep is now written in Cython, we can't simply
move the code over to libsepol. My guess is dispol has the most useful building
blocks for making a new API.
Since you mention dispol... I also had the idea that setools could
just use the existing public interface to convert the whole policydb
to CIL and simply parse that as a string (this should be pretty
straightforward even in pure Python). However, based on my experiments
this would likely make setools a lot slower...
This is an interesting idea. I'm not familiar with the CIL API; secilc.c looks
like it uses public API. Can I use the existing CIL library functions to parse
it, or does the resultant db lack public accessor functions?
--
Chris PeBenito
