On Thu, Apr 30, 2020 at 11:20 AM Chris PeBenito <pebenito@xxxxxxxx> wrote: > > 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? > The resultant db does, in fact, lack public assessor functions. They could be created, but since there is already a way to convert the cil_db to a policydb, the general solution would be to create the functions for the policydb. Jim
