On Thu, Apr 30, 2020 at 9:23 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> 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 am so used to everything just using the stuff in include/sepol/policydb/ that I forget that it exists. There are a number of iterators there (for users, ports, nodes, etc), so it seems like creating an iterator and other functions for filename transition rules and converting setools to use that would be the first step. Over time other iterators can be created and setools converted to use those as well. Jim
