On Thu, Apr 30, 2020 at 3:23 PM 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/. We could also partially mitigate the problem by linking libsepol statically into setools at build time. I suggested this in [1] for Fedora at least, but in general there is the problem that you need to know the exact path to libsepol.a in setup.py [2]. I don't have enough experience with python libraries to know if this can be implemented directly in the upstream setup.py script in a reasonably generic way. If linked statically, at least it wouldn't segfault after an update to an incompatible libsepol.so. It would still fail to build with the new headers, but at least this turns from a user-visible bug to only packager's & maintainer's problem. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1826000 [2] https://stackoverflow.com/questions/4597228/how-to-statically-link-a-library-when-compiling-a-python-module-extension/49139257#49139257 -- Ondrej Mosnacek <omosnace at redhat dot com> Software Engineer, Security Technologies Red Hat, Inc.
