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... -- Ondrej Mosnacek <omosnace at redhat dot com> Software Engineer, Security Technologies Red Hat, Inc.
