Re: [RFC] Split up policycoreutils

[Dominick Grift <dac.override@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 5643 bytes --]

On 10/31/2016 07:23 PM, Stephen Smalley wrote:
> On 10/31/2016 02:15 PM, Dominick Grift wrote:
>> On 10/31/2016 07:05 PM, Stephen Smalley wrote:
>>> On 10/21/2016 01:47 PM, Stephen Smalley wrote:
>>>> Hi,
>>>>
>>>> policycoreutils started life as a small set of utilities that
>>>> were necessary or at least widely used in production on a
>>>> SELinux system. Over time though it has grown to include many
>>>> optional components, and even within a given subdirectory (e.g.
>>>> sepolicy) there seem to be a number of components that should
>>>> be optional (e.g. the dbus service). I'd like to propose that
>>>> we move a number of components out of policycoreutils into
>>>> their own top-level subdirectory (possibly grouping some of the
>>>> related ones together).
>>>>
>>>> Some possible components to move and the rationale for doing so
>>>> include:
>>>>
>>>> - gui: not required for operation.  Unsure if this is even used
>>>> outside of Fedora, or how widely it is used within Fedora
>>>> compared to the command line tools. Packaged separately by
>>>> Fedora as part of policycoreutils-gui.
>>>>
>>>> - mcstrans: not required for operation outside of MLS
>>>> environments (and even there, only if using that label encoding
>>>> functionality), not built by default even upstream (omitted
>>>> from policycoreutils/Makefile). Packaged separately in Fedora
>>>> as mcstrans.
>>>>
>>>> - restorecond: not required for operation, adds dbus and glib 
>>>> dependencies, largely obsoleted by name-based type transition
>>>> support in the kernel.  Packaged separately in Fedora as
>>>> policycoreutils-restorecond.
>>>>
>>>> - sandbox: not required for basic operation of SELinux.
>>>> Packaged separately by Fedora as policycoreutils-sandbox. 
>>>> restorecond - semodule_deps/expand/link: developer tools only,
>>>> not required for operation, unlike semodule.  Packaged
>>>> separately by Fedora as part of policycoreutils-devel.
>>>>
>>>> - sepolicy/{org.selinux*,selinux_client.py,selinux_server.py}:
>>>> D-BUS service for managing SELinux, not required for basic
>>>> operation, not desirable in high security environments.
>>>> Packaged separately by Fedora as part of policycoreutils-gui.
>>>> Could perhaps be combined with the gui above, although I think
>>>> they are logically distinct.
>>>>
>>>> We could of course go further, but those seem to be the most
>>>> obvious candidates.
>>>>
>>>> Thoughts?
>>>
>>> For discussion purposes, I've pushed a splitpolicycoreutils
>>> branch that moves the above components and others identified in
>>> the discussion thread, and makes it easy to omit the non-core
>>> components from the build.  Take a look and see what you think.
>>> Known issues:
>>>
>>> - I did not deal with splitting the policycoreutils/po files and
>>> moving them around.  Not sure what the best way to handle that
>>> is.
>>>
>>> - python/sepolicy likely needs further rearrangement. I am
>>> unclear on the purpose/use of the desktop file and pixmaps; if
>>> those are only for the gui, then they can be moved to gui/, but I
>>> don't understand why they are called sepolicy* or located here.
>>> Also, should python/sepolicy/sepolicy/sedbus.py be moved over to
>>> dbus/ or stay here? Dan?
>>>
>>> - dbus/selinux_client.py (formerly 
>>> policycoreutils/sepolicy/selinux_client.py) seems like leftover
>>> testing cruft.  Remove?
>>>
>>> - restorecond presently reuses source code directly from
>>> setfiles, so building it as a separate package may be a nuisance.
>>> OTOH, I'm not entirely clear on whether restorecond needs to be
>>> kept around at all anymore?
>>>
>>> - policycoreutils/sepolgen-ifgen contains a single C program, 
>>> sepolgen-ifgen-attr-helper, that is only used by 
>>> python/audit2allow/sepolgen-ifgen.  Any reason to not just
>>> coalesce it into python/audit2allow even though it is not python
>>> itself?
>>>
>>> - After the restructuring, the only script left in
>>> policycoreutils is fixfiles.  Technically, that's not required
>>> for production either as one can always just run setfiles or
>>> restorecon directly, but distros seem to rely on it.  Is it worth
>>> moving just to free policycoreutils of any bash dependencies, and
>>> if so, where?
>>>
>>> - I moved policycoreutils/semodule_{deps,expand,link} into a new 
>>> semodule-utils directory.  This might however be slightly
>>> confusing since semodule and semodule_package remain in
>>> policycoreutils since they are required and not merely for
>>> developers.  Feel free to suggest another name or structure.
>>> Actually, I guess semodule_package might be optional now with
>>> CIL, so perhaps that one can be moved too.
>>
>> sepolgen-ifgen is reference policy specific and thus not core
>>
>> also i would move run_init and newrole out of policycoreutils
> 
> You didn't cc the list?
> 
> I think the problem is that if we keep pulling that thread, we'll
> quickly get to the point where nothing is left in policycoreutils at
> all.  sepolgen-ifgen I agree with.  run_init and newrole have been
> part of core SELinux from the beginning and are pretty fundamental
> especially in a confined user environment.
> 
> 

Whoops, Cc'ing the list

Okay, yes, ideally my policycoreutils would look like this:

setfiles
load_policy
secon
restorecon
setsebool/getsebool

But i see your point and i can live with that


-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]