On 10/21/2016 07: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.
>
> - 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?
Generally the split makes sense to me.
DBUS is used for generic interprocess communication even in low level
system components like init and it's basically a mandatory component of
so called modern systems. There are projects like Cockpit -
http://cockpit-project.org/ - which uses DBUS as API to access and
manage system resources.
So I think that org.selinux DBUS API and selinux_server.py should be
extracted from sepolicy to its own subdirectory to be available to all
other projects without need to install gui application and libraries.
Then sepolicy/ and gui/ could follow the current structure with a
dependency on dbus/.
Petr
_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
