All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: SELinux <selinux@tycho.nsa.gov>
Subject: [RFC] Split up policycoreutils
Date: Fri, 21 Oct 2016 13:47:58 -0400	[thread overview]
Message-ID: <4633f93f-9a5e-65e8-12d6-f11160be316f@tycho.nsa.gov> (raw)

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?

             reply	other threads:[~2016-10-21 17:46 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21 17:47 Stephen Smalley [this message]
2016-10-21 18:11 ` [RFC] Split up policycoreutils Daniel J Walsh
2016-10-21 21:06   ` Paul Moore
2016-10-22 13:44 ` Chris PeBenito
2016-10-24 13:13   ` Stephen Smalley
2016-10-24 13:16     ` Dominick Grift
2016-10-24 13:21     ` Stephen Smalley
2016-10-24 21:15       ` Daniel J Walsh
2016-10-25  5:47         ` Dominick Grift
2016-10-31  9:27       ` Sven Vermeulen
2016-10-31 14:29         ` Stephen Smalley
2016-10-25  3:49     ` Jason Zaman
2016-10-25 22:12       ` Chris PeBenito
2016-10-24  9:28 ` Petr Lautrbach
2016-10-24 12:33 ` Sven Vermeulen
2016-10-31 18:05 ` Stephen Smalley
2016-10-31 18:11   ` Dominick Grift
     [not found]   ` <eaeb9dc4-e69f-47de-50ad-083ce97e1153@gmail.com>
     [not found]     ` <98931665-f141-29e3-fb3a-9335e58874b0@tycho.nsa.gov>
2016-10-31 18:26       ` Dominick Grift
2016-10-31 18:42   ` Stephen Smalley
2016-11-01 19:00   ` Daniel J Walsh
2016-11-08 19:42   ` Stephen Smalley
2016-11-14 20:41     ` Jason Zaman
2016-11-15 14:47       ` Stephen Smalley
2016-11-15 15:01         ` Stephen Smalley
2016-11-15 16:30           ` Jason Zaman
2016-11-16 19:00             ` Stephen Smalley
2016-11-16 19:07               ` Stephen Smalley
2016-11-18 12:40         ` Daniel J Walsh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4633f93f-9a5e-65e8-12d6-f11160be316f@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.