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:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
