[RFC] Split up policycoreutils

[RFC] Split up policycoreutils

[Stephen Smalley]

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?

Re: [RFC] Split up policycoreutils

[Daniel J Walsh]

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.
>
> - 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?
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
>
I am fine with this. For the most part we have separated them apart in
Red Hat based Distributions.

Re: [RFC] Split up policycoreutils

[Paul Moore]

On Fri, Oct 21, 2016 at 2:11 PM, Daniel J Walsh <dwalsh@redhat.com> 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.
>>
>> - 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?
>
> I am fine with this. For the most part we have separated them apart in
> Red Hat based Distributions.

Agree with Dan, no problem with me.  It will add a small amount of
difficulty to backporting fixes to distributions, but it shouldn't be
too bad and this is arguably the right thing to do moving forward.

-- 
paul moore
www.paul-moore.com

Re: [RFC] Split up policycoreutils

[Chris PeBenito]

On 10/21/16 13:47, Stephen Smalley wrote:
> 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).

I'm not sure where the main part of sepolicy should go, but it would be 
nice to split it out since it depends on setools which has heavier 
dependencies than a core system package should typically have IMO 
(NetworkX, which pulls in scipy, numpy, matplotlib, etc.)

-- 
Chris PeBenito

Re: [RFC] Split up policycoreutils

[Petr Lautrbach]

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

Re: [RFC] Split up policycoreutils

[Sven Vermeulen]

On Fri, Oct 21, 2016 at 7:47 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 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).
[... gui, mcstrans, restorecond, sandbox, semodule_*, sepolicy ...]

I don't see a problem going forward with this. We'll have some package
management effort to do in Gentoo then (we haven't split that like
Fedora did, but used USE flags to toggle the building of certain
areas) but that's manageable.

Wkr,
  Sven Vermeulen

Re: [RFC] Split up policycoreutils

[Stephen Smalley]

On 10/22/2016 09:44 AM, Chris PeBenito wrote:
> On 10/21/16 13:47, Stephen Smalley wrote:
>> 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).
> 
> I'm not sure where the main part of sepolicy should go, but it would be
> nice to split it out since it depends on setools which has heavier
> dependencies than a core system package should typically have IMO
> (NetworkX, which pulls in scipy, numpy, matplotlib, etc.)

I would be in favor of that too, but hesitated to do so because it would
require moving audit2allow and semanage out of policycoreutils as well.
Fedora does package those as part of policycoreutils-python (along with
sepolgen).  Arguably audit2allow isn't necessary for production (but
many users of SELinux in Linux distributions rely on it), but semanage
is more fundamental these days.

However, if people are open to moving sepolicy, audit2allow, and
semanage, possibly combining them with sepolgen in a new
subdirectory/package, then we could explore that.

Re: [RFC] Split up policycoreutils

[Dominick Grift]

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

On 10/24/2016 03:13 PM, Stephen Smalley wrote:
> On 10/22/2016 09:44 AM, Chris PeBenito wrote:
>> On 10/21/16 13:47, Stephen Smalley wrote:
>>> 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).
>>
>> I'm not sure where the main part of sepolicy should go, but it would be
>> nice to split it out since it depends on setools which has heavier
>> dependencies than a core system package should typically have IMO
>> (NetworkX, which pulls in scipy, numpy, matplotlib, etc.)
> 
> I would be in favor of that too, but hesitated to do so because it would
> require moving audit2allow and semanage out of policycoreutils as well.
> Fedora does package those as part of policycoreutils-python (along with
> sepolgen).  Arguably audit2allow isn't necessary for production (but
> many users of SELinux in Linux distributions rely on it), but semanage
> is more fundamental these days.
> 
> However, if people are open to moving sepolicy, audit2allow, and
> semanage, possibly combining them with sepolgen in a new
> subdirectory/package, then we could explore that.
> 

Yes please. These aren't needed or feasible in a CIL only config

> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> 


-- 
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 --]

Re: [RFC] Split up policycoreutils

[Stephen Smalley]

On 10/24/2016 09:13 AM, Stephen Smalley wrote:
> On 10/22/2016 09:44 AM, Chris PeBenito wrote:
>> On 10/21/16 13:47, Stephen Smalley wrote:
>>> 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).
>>
>> I'm not sure where the main part of sepolicy should go, but it would be
>> nice to split it out since it depends on setools which has heavier
>> dependencies than a core system package should typically have IMO
>> (NetworkX, which pulls in scipy, numpy, matplotlib, etc.)
> 
> I would be in favor of that too, but hesitated to do so because it would
> require moving audit2allow and semanage out of policycoreutils as well.
> Fedora does package those as part of policycoreutils-python (along with
> sepolgen).  Arguably audit2allow isn't necessary for production (but
> many users of SELinux in Linux distributions rely on it), but semanage
> is more fundamental these days.
> 
> However, if people are open to moving sepolicy, audit2allow, and
> semanage, possibly combining them with sepolgen in a new
> subdirectory/package, then we could explore that.

We'd also need to move chcat, since it imports seobject.  However, on
that topic, is there any reason to retain chcat?  It was created for the
original discretionary MCS model and I'm not sure it is used anymore by
anyone.

Re: [RFC] Split up policycoreutils

[Daniel J Walsh]

On 10/24/2016 09:21 AM, Stephen Smalley wrote:
> On 10/24/2016 09:13 AM, Stephen Smalley wrote:
>> On 10/22/2016 09:44 AM, Chris PeBenito wrote:
>>> On 10/21/16 13:47, Stephen Smalley wrote:
>>>> 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).
>>> I'm not sure where the main part of sepolicy should go, but it would be
>>> nice to split it out since it depends on setools which has heavier
>>> dependencies than a core system package should typically have IMO
>>> (NetworkX, which pulls in scipy, numpy, matplotlib, etc.)
>> I would be in favor of that too, but hesitated to do so because it would
>> require moving audit2allow and semanage out of policycoreutils as well.
>> Fedora does package those as part of policycoreutils-python (along with
>> sepolgen).  Arguably audit2allow isn't necessary for production (but
>> many users of SELinux in Linux distributions rely on it), but semanage
>> is more fundamental these days.
>>
>> However, if people are open to moving sepolicy, audit2allow, and
>> semanage, possibly combining them with sepolgen in a new
>> subdirectory/package, then we could explore that.
> We'd also need to move chcat, since it imports seobject.  However, on
> that topic, is there any reason to retain chcat?  It was created for the
> original discretionary MCS model and I'm not sure it is used anymore by
> anyone.
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
>
I would suggest we remove it.

Re: [RFC] Split up policycoreutils

[Jason Zaman]

On Mon, Oct 24, 2016 at 09:13:42AM -0400, Stephen Smalley wrote:
> On 10/22/2016 09:44 AM, Chris PeBenito wrote:
> > On 10/21/16 13:47, Stephen Smalley wrote:
> >> 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).

I'm also in favour of splitting. As Sven said, we conditionally compile
things with USE-flags in gentoo instead of separate packages but that
can easily change. Live would probably be easier since then there would
be no patching to make it conditional.
We dont even package sandbox and quite a few other things at all. We do
also have a policycoreutils-extra (has rlpkg and a few other things)
which I have been meaning to upstream but havent gotten around to it
yet. If things are getting split those could be added to whatever
policyextrautils package we end up with.


> > I'm not sure where the main part of sepolicy should go, but it would be
> > nice to split it out since it depends on setools which has heavier
> > dependencies than a core system package should typically have IMO
> > (NetworkX, which pulls in scipy, numpy, matplotlib, etc.)
> 
> I would be in favor of that too, but hesitated to do so because it would
> require moving audit2allow and semanage out of policycoreutils as well.
> Fedora does package those as part of policycoreutils-python (along with
> sepolgen).  Arguably audit2allow isn't necessary for production (but
> many users of SELinux in Linux distributions rely on it), but semanage
> is more fundamental these days.
> 
> However, if people are open to moving sepolicy, audit2allow, and
> semanage, possibly combining them with sepolgen in a new
> subdirectory/package, then we could explore that.

My eventual goal for seobject.py was to just kill it, there isnt really
anything that setools4 doesnt have. For the last release mostly due to
lack of time I changed several parts to just be sort of thin wrappers
around setools.

sepolicy also seemed like two separate things. one part was a kind of
library thing which i updated to use setools4 too, that would be better
off dying or being a separate small lib. then there is the whole gui
part of sepolicy which can probably be split out. I dont think i've ever
personally used the gui. semanage only requires the lib parts.

I havent looked too much into the core of setools4 other than what I
needed to update sepolicy so I'm not sure how important networkX and
stuff are. semanage might only require the base stuff if we're able to
split that out?

-- Jason

Re: [RFC] Split up policycoreutils

[Dominick Grift]

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

On 10/24/2016 11:15 PM, Daniel J Walsh wrote:
> 
> 
> On 10/24/2016 09:21 AM, Stephen Smalley wrote:
>> On 10/24/2016 09:13 AM, Stephen Smalley wrote:
>>> On 10/22/2016 09:44 AM, Chris PeBenito wrote:
>>>> On 10/21/16 13:47, Stephen Smalley wrote:
>>>>> 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).
>>>> I'm not sure where the main part of sepolicy should go, but it would be
>>>> nice to split it out since it depends on setools which has heavier
>>>> dependencies than a core system package should typically have IMO
>>>> (NetworkX, which pulls in scipy, numpy, matplotlib, etc.)
>>> I would be in favor of that too, but hesitated to do so because it would
>>> require moving audit2allow and semanage out of policycoreutils as well.
>>> Fedora does package those as part of policycoreutils-python (along with
>>> sepolgen).  Arguably audit2allow isn't necessary for production (but
>>> many users of SELinux in Linux distributions rely on it), but semanage
>>> is more fundamental these days.
>>>
>>> However, if people are open to moving sepolicy, audit2allow, and
>>> semanage, possibly combining them with sepolgen in a new
>>> subdirectory/package, then we could explore that.
>> We'd also need to move chcat, since it imports seobject.  However, on
>> that topic, is there any reason to retain chcat?  It was created for the
>> original discretionary MCS model and I'm not sure it is used anymore by
>> anyone.
>>
>>
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>>
>>
> I would suggest we remove it.

I would not mind terribly removing it either but I prefer that we first
see if we can fit this in somewhere else. I do not see this as a core
utility but if someone wants to implement the old MCS model then one
should be able to do so.

> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> 


-- 
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 --]

Re: [RFC] Split up policycoreutils

[Chris PeBenito]

On 10/24/16 23:49, Jason Zaman wrote:
> On Mon, Oct 24, 2016 at 09:13:42AM -0400, Stephen Smalley wrote:
>> On 10/22/2016 09:44 AM, Chris PeBenito wrote:
>>> On 10/21/16 13:47, Stephen Smalley wrote:
>>> I'm not sure where the main part of sepolicy should go, but it would be
>>> nice to split it out since it depends on setools which has heavier
>>> dependencies than a core system package should typically have IMO
>>> (NetworkX, which pulls in scipy, numpy, matplotlib, etc.)
>>
>> I would be in favor of that too, but hesitated to do so because it would
>> require moving audit2allow and semanage out of policycoreutils as well.
>> Fedora does package those as part of policycoreutils-python (along with
>> sepolgen).  Arguably audit2allow isn't necessary for production (but
>> many users of SELinux in Linux distributions rely on it), but semanage
>> is more fundamental these days.
>>
>> However, if people are open to moving sepolicy, audit2allow, and
>> semanage, possibly combining them with sepolgen in a new
>> subdirectory/package, then we could explore that.
>
> My eventual goal for seobject.py was to just kill it, there isnt really
> anything that setools4 doesnt have. For the last release mostly due to
> lack of time I changed several parts to just be sort of thin wrappers
> around setools.
>
> sepolicy also seemed like two separate things. one part was a kind of
> library thing which i updated to use setools4 too, that would be better
> off dying or being a separate small lib. then there is the whole gui
> part of sepolicy which can probably be split out. I dont think i've ever
> personally used the gui. semanage only requires the lib parts.
>
> I havent looked too much into the core of setools4 other than what I
> needed to update sepolicy so I'm not sure how important networkX and
> stuff are. semanage might only require the base stuff if we're able to
> split that out?

NetworkX is a dependency for the domain transition and information flow 
analyses only.  You could conceivably make those conditional, but I'm 
not particularly fond of the idea.

-- 
Chris PeBenito

Re: [RFC] Split up policycoreutils

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Oct 24, 2016 3:19 PM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
> We'd also need to move chcat, since it imports seobject.  However, on
> that topic, is there any reason to retain chcat?  It was created for the
> original discretionary MCS model and I'm not sure it is used anymore by
> anyone.

I am aware of at least one company using chcat. However, I don't know to
what extend they rely on it - they use it in their user provisioning
scripts.

I don't mind getting rid of it, assuming all its functionality is covered
elsewhere. Especially using the tool(s) in unattended scripts.

Wkr,
  Sven Vermeulen

[-- Attachment #2: Type: text/html, Size: 794 bytes --]

Re: [RFC] Split up policycoreutils

[Stephen Smalley]

On 10/31/2016 05:27 AM, Sven Vermeulen wrote:
> On Oct 24, 2016 3:19 PM, "Stephen Smalley" <sds@tycho.nsa.gov
> <mailto:sds@tycho.nsa.gov>> wrote:
>> We'd also need to move chcat, since it imports seobject.  However, on
>> that topic, is there any reason to retain chcat?  It was created for the
>> original discretionary MCS model and I'm not sure it is used anymore by
>> anyone.
> 
> I am aware of at least one company using chcat. However, I don't know to
> what extend they rely on it - they use it in their user provisioning
> scripts.
> 
> I don't mind getting rid of it, assuming all its functionality is
> covered elsewhere. Especially using the tool(s) in unattended scripts.

I think that for that situation chcat is just invoking semanage login
with appropriate arguments, so you could just directly invoke semanage.

Re: [RFC] Split up policycoreutils

[Stephen Smalley]

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.

Re: [RFC] Split up policycoreutils

[Dominick Grift]

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

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.

semodule itself is also optional and not only with CIL but also with
monolitic policy.

maybe:

semodule (just semodule)
semodule-utils (all the other semodule related)

> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> 


-- 
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 --]

Re: [RFC] Split up policycoreutils

[Dominick Grift]

[-- 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 --]

Re: [RFC] Split up policycoreutils

[Stephen Smalley]

On 10/31/2016 02: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?

Actually, I suspect this helper program could be rewritten in python to
use the setools4 interfaces these days.

> 
> - 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.
> 

Re: [RFC] Split up policycoreutils

[Daniel J Walsh]

On 10/31/2016 02: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.
We might want to copy each one to every package, but the python code
will need to be changed, and we will need to set up the translators to
include the new packages.  Most of the po files are for the gui though.
> - 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?
Desktop files and pixmaps are just for the GUIs.   sedbus.py is a dbus
interace for
sepolicy.  I would think the dbus interfaces should stay with the low
level tools.


> - dbus/selinux_client.py (formerly
> policycoreutils/sepolicy/selinux_client.py) seems like leftover testing
> cruft.  Remove?
This is just a test tool for testing out the dbus interface.  Could be
renamed selinux_dbus_client
and not installed.  Removing it would make it harder to test debug dbus
interfaces.
> - 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?
I think restorecond is still used by some people.  But it is not needed
as much as it used
to be, because of file name transitions, and mv -Z type support.
> - 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?
Seems reasonable.
> - 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?
It is needed by the selinux-policy package.  Used in post install to
limit the relabeling
of the system on file context changes.  I would keep this in
policycoreutils.
> - 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.
>

Re: [RFC] Split up policycoreutils

[Stephen Smalley]

On 10/31/2016 02: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.

I've made further changes on the splitpolicycoreutils branch based on
the discussion (as well as rebasing it on latest master).  This is a
call for final comments or objections before merging it to master.  With
the current branch, we will have the following source tar files in a
release:

Unchanged:
* libsepol
* libselinux
* libsemanage
* checkpolicy
* secilc

Modified or new:
* policycoreutils (containing only hll, load_policy, newrole, run_init,
scripts/fixfiles, secon, semodule, sestatus, setfiles, setsebool)
* mcstrans
* restorecond
* semodule-utils (containing semodule_package, semodule_link,
semodule_expand, semodule_deps)
* selinux-dbus (containing org.selinux DBus configuration and python files)
- selinux-gui (containing system-config-selinux aka selinux polgengui)
- selinux-python (containing audit2allow, including its
sepolgen-ifgen-attr-helper helper program, chcat, semanage, sepolgen,
sepolicy)
- selinux-sandbox (containing sandbox)

No longer separate:
* sepolgen (moved inside of selinux-python)

Note that the release script will add the selinux- prefix for dbus, gui,
python, and sandbox when generating the source tarballs so that they
have unique names suitable for source packages.

Feel free to suggest changes in structure, naming, or whatever.

Re: [RFC] Split up policycoreutils

[Jason Zaman]

On Tue, Nov 08, 2016 at 02:42:31PM -0500, Stephen Smalley wrote:
> On 10/31/2016 02: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.
> 
> I've made further changes on the splitpolicycoreutils branch based on
> the discussion (as well as rebasing it on latest master).  This is a
> call for final comments or objections before merging it to master.  With
> the current branch, we will have the following source tar files in a
> release:
> 
> Unchanged:
> * libsepol
> * libselinux
> * libsemanage
> * checkpolicy
> * secilc
> 
> Modified or new:
> * policycoreutils (containing only hll, load_policy, newrole, run_init,
> scripts/fixfiles, secon, semodule, sestatus, setfiles, setsebool)
> * mcstrans
> * restorecond
> * semodule-utils (containing semodule_package, semodule_link,
> semodule_expand, semodule_deps)
> * selinux-dbus (containing org.selinux DBus configuration and python files)
> - selinux-gui (containing system-config-selinux aka selinux polgengui)
> - selinux-python (containing audit2allow, including its
> sepolgen-ifgen-attr-helper helper program, chcat, semanage, sepolgen,
> sepolicy)
> - selinux-sandbox (containing sandbox)
> 
> No longer separate:
> * sepolgen (moved inside of selinux-python)

These look pretty good to me. I have written most of the ebuilds for
gentoo for these new packages but have not committed to the tree yet.

There are a couple issues:
1) What is the license for each of the tarballs? there is no license or
COPYING file in the dirs.

2) even tho i fixed up a lot of it so shouldnt be, I am *super* confused
about sepolicy vs sepolgen. there are like 4 separate dirs with those
names and the sepolicy Makefile makes a symlink for sepolgen. And then
there is the gui and the non-gui part of them. python/sepolicy/* should
hopefully die soon as things fully move over to setools4. should gui/ be
called system-config-selinux? also is it a redhatism or does it also
apply to other distros?

3) The deps of each of the bits is somewhat complicated to figure out.
semodule-utils looks like it only needs libsepol and libselinux and the
others look like they need most of the others? The makefile just builds
them in order but i'd like to specify more accurate deps in the gentoo
packages (especially external deps for each package) so they get
(re)built as required as things update.

Also which of these are required to build refpolicy? the docs on that
may need updating later too.

4) mcstrans fails to build on my laptop, i'll send patches later. I
might have stricter warnings on or something.

5) in python/sepolicy/Makefile:
override CFLAGS += -I$(PREFIX)/include -DPACKAGE="policycoreutils"
should that be something instead of policycoreutils now?

6) we have a policycoreutils-extra thats been floating around as part of
policycoreutils in gentoo. Mainly has rlpkg and selocal. After this
split is as good a time as any to cleanup and upstream them.

7) I just noticed when looking through different Makefiles that some
variables default to different things. I'll send patches for this too
later once its merged in. Its nothing huge just better to be the same.

> Note that the release script will add the selinux- prefix for dbus, gui,
> python, and sandbox when generating the source tarballs so that they
> have unique names suitable for source packages.

This makes sense but I wonder if the name prefix is going to be annoying
when we end up needing to backport a patch on a release since the paths
would be different. But then again we've always had to edit them since
they are one level down so I dont think I mind this minor extra bit too.

-- Jason

Re: [RFC] Split up policycoreutils

[Stephen Smalley]

On 11/14/2016 03:41 PM, Jason Zaman wrote:
> These look pretty good to me. I have written most of the ebuilds for
> gentoo for these new packages but have not committed to the tree yet.
> 
> There are a couple issues:
> 1) What is the license for each of the tarballs? there is no license or
> COPYING file in the dirs.

Fixed; I copied the policycoreutils/COPYING file into each of the new
ones since they were all moved from policycoreutils.

> 
> 2) even tho i fixed up a lot of it so shouldnt be, I am *super* confused
> about sepolicy vs sepolgen. there are like 4 separate dirs with those
> names and the sepolicy Makefile makes a symlink for sepolgen. And then
> there is the gui and the non-gui part of them. python/sepolicy/* should
> hopefully die soon as things fully move over to setools4. should gui/ be
> called system-config-selinux? also is it a redhatism or does it also
> apply to other distros?

I also find this confusing; hopefully Dan (cc'd) can help clarify
matters since he wrote most of this code.  I do know that the old
sepolgen package (now python/sepolgen) was just a python module used as
the backend for audit2allow and intended to become a more general policy
analysis and generation backend, but never evolved that way, whereas
gui/sepolgen was the old name for Dan's policy generation script/tool
that is now just an alias for sepolicy generate. gui could be called
system-config-selinux, but then it can also be invoked as sepolicy gui.
It certainly started life as a Red Hat tool, but I'm not sure if anyone
else is using it.  Refactoring all of it, including
semanage/seobject.py, may make sense.

> 3) The deps of each of the bits is somewhat complicated to figure out.
> semodule-utils looks like it only needs libsepol and libselinux and the
> others look like they need most of the others? The makefile just builds
> them in order but i'd like to specify more accurate deps in the gentoo
> packages (especially external deps for each package) so they get
> (re)built as required as things update.

I was also trying to make it easy to omit the optional components
(OPT_SUBDIRS in the top-level Makefile), i.e. the ones that are not
required for operation.  I would omit at least dbus, gui, mcstrans,
restorecond, and sandbox by default from a base install.  python is
likely needed for general purpose distros but could be omitted from
embedded systems.  Actually, I don't see why semodule-utils components
are linking with libselinux; they do not include selinux.h or make any
calls to libselinux AFAICS, so I think that only truly depends on libsepol.

> Also which of these are required to build refpolicy? the docs on that
> may need updating later too.

I would only expect libsepol, checkpolicy, and semodule-utils to be
needed to build refpolicy, while libsemanage and policycoreutils would
also be needed to install/load refpolicy.

> 4) mcstrans fails to build on my laptop, i'll send patches later. I
> might have stricter warnings on or something.

Ok, I already had to fix a number of such warnings for it when I
re-enabled building it by default on that branch (it was disabled
before), so not surprised - just send the patches our way.

> 5) in python/sepolicy/Makefile:
> override CFLAGS += -I$(PREFIX)/include -DPACKAGE="policycoreutils"
> should that be something instead of policycoreutils now?

Probably can be removed entirely.

> 6) we have a policycoreutils-extra thats been floating around as part of
> policycoreutils in gentoo. Mainly has rlpkg and selocal. After this
> split is as good a time as any to cleanup and upstream them.

Ok, in that case we might want to think about what else if anything
might go there.

> 7) I just noticed when looking through different Makefiles that some
> variables default to different things. I'll send patches for this too
> later once its merged in. Its nothing huge just better to be the same.
> 
>> Note that the release script will add the selinux- prefix for dbus, gui,
>> python, and sandbox when generating the source tarballs so that they
>> have unique names suitable for source packages.
> 
> This makes sense but I wonder if the name prefix is going to be annoying
> when we end up needing to backport a patch on a release since the paths
> would be different. But then again we've always had to edit them since
> they are one level down so I dont think I mind this minor extra bit too.

Open to suggestions; I could add the prefix in the source tree itself;
it just seemed ugly/unnecessary.  Or we could split up the repository
into multiple ones / submodules, but I'm not keen on that.

Re: [RFC] Split up policycoreutils

[Stephen Smalley]

On 11/15/2016 09:47 AM, Stephen Smalley wrote:
> On 11/14/2016 03:41 PM, Jason Zaman wrote:
>> These look pretty good to me. I have written most of the ebuilds for
>> gentoo for these new packages but have not committed to the tree yet.
>>
>> There are a couple issues:
>> 1) What is the license for each of the tarballs? there is no license or
>> COPYING file in the dirs.
> 
> Fixed; I copied the policycoreutils/COPYING file into each of the new
> ones since they were all moved from policycoreutils.
> 
>>
>> 2) even tho i fixed up a lot of it so shouldnt be, I am *super* confused
>> about sepolicy vs sepolgen. there are like 4 separate dirs with those
>> names and the sepolicy Makefile makes a symlink for sepolgen. And then
>> there is the gui and the non-gui part of them. python/sepolicy/* should
>> hopefully die soon as things fully move over to setools4. should gui/ be
>> called system-config-selinux? also is it a redhatism or does it also
>> apply to other distros?
> 
> I also find this confusing; hopefully Dan (cc'd) can help clarify
> matters since he wrote most of this code.  I do know that the old
> sepolgen package (now python/sepolgen) was just a python module used as
> the backend for audit2allow and intended to become a more general policy
> analysis and generation backend, but never evolved that way, whereas
> gui/sepolgen was the old name for Dan's policy generation script/tool
> that is now just an alias for sepolicy generate. gui could be called
> system-config-selinux, but then it can also be invoked as sepolicy gui.
> It certainly started life as a Red Hat tool, but I'm not sure if anyone
> else is using it.  Refactoring all of it, including
> semanage/seobject.py, may make sense.
> 
>> 3) The deps of each of the bits is somewhat complicated to figure out.
>> semodule-utils looks like it only needs libsepol and libselinux and the
>> others look like they need most of the others? The makefile just builds
>> them in order but i'd like to specify more accurate deps in the gentoo
>> packages (especially external deps for each package) so they get
>> (re)built as required as things update.
> 
> I was also trying to make it easy to omit the optional components
> (OPT_SUBDIRS in the top-level Makefile), i.e. the ones that are not
> required for operation.  I would omit at least dbus, gui, mcstrans,
> restorecond, and sandbox by default from a base install.  python is
> likely needed for general purpose distros but could be omitted from
> embedded systems.  Actually, I don't see why semodule-utils components
> are linking with libselinux; they do not include selinux.h or make any
> calls to libselinux AFAICS, so I think that only truly depends on libsepol.

Fixed this too on the branch - removed the -lselinux from semodule-utils
Makefiles.
> 
>> Also which of these are required to build refpolicy? the docs on that
>> may need updating later too.
> 
> I would only expect libsepol, checkpolicy, and semodule-utils to be
> needed to build refpolicy, while libsemanage and policycoreutils would
> also be needed to install/load refpolicy.
> 
>> 4) mcstrans fails to build on my laptop, i'll send patches later. I
>> might have stricter warnings on or something.
> 
> Ok, I already had to fix a number of such warnings for it when I
> re-enabled building it by default on that branch (it was disabled
> before), so not surprised - just send the patches our way.
> 
>> 5) in python/sepolicy/Makefile:
>> override CFLAGS += -I$(PREFIX)/include -DPACKAGE="policycoreutils"
>> should that be something instead of policycoreutils now?
> 
> Probably can be removed entirely.
> 
>> 6) we have a policycoreutils-extra thats been floating around as part of
>> policycoreutils in gentoo. Mainly has rlpkg and selocal. After this
>> split is as good a time as any to cleanup and upstream them.
> 
> Ok, in that case we might want to think about what else if anything
> might go there.
> 
>> 7) I just noticed when looking through different Makefiles that some
>> variables default to different things. I'll send patches for this too
>> later once its merged in. Its nothing huge just better to be the same.
>>
>>> Note that the release script will add the selinux- prefix for dbus, gui,
>>> python, and sandbox when generating the source tarballs so that they
>>> have unique names suitable for source packages.
>>
>> This makes sense but I wonder if the name prefix is going to be annoying
>> when we end up needing to backport a patch on a release since the paths
>> would be different. But then again we've always had to edit them since
>> they are one level down so I dont think I mind this minor extra bit too.
> 
> Open to suggestions; I could add the prefix in the source tree itself;
> it just seemed ugly/unnecessary.  Or we could split up the repository
> into multiple ones / submodules, but I'm not keen on that.
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> 

Re: [RFC] Split up policycoreutils

[Jason Zaman]

On Tue, Nov 15, 2016 at 10:01:12AM -0500, Stephen Smalley wrote:
> On 11/15/2016 09:47 AM, Stephen Smalley wrote:
> > On 11/14/2016 03:41 PM, Jason Zaman wrote:
> >> These look pretty good to me. I have written most of the ebuilds for
> >> gentoo for these new packages but have not committed to the tree yet.
> >>
> >> There are a couple issues:
> >> 1) What is the license for each of the tarballs? there is no license or
> >> COPYING file in the dirs.
> > 
> > Fixed; I copied the policycoreutils/COPYING file into each of the new
> > ones since they were all moved from policycoreutils.
> > 
> >>
> >> 2) even tho i fixed up a lot of it so shouldnt be, I am *super* confused
> >> about sepolicy vs sepolgen. there are like 4 separate dirs with those
> >> names and the sepolicy Makefile makes a symlink for sepolgen. And then
> >> there is the gui and the non-gui part of them. python/sepolicy/* should
> >> hopefully die soon as things fully move over to setools4. should gui/ be
> >> called system-config-selinux? also is it a redhatism or does it also
> >> apply to other distros?
> > 
> > I also find this confusing; hopefully Dan (cc'd) can help clarify
> > matters since he wrote most of this code.  I do know that the old
> > sepolgen package (now python/sepolgen) was just a python module used as
> > the backend for audit2allow and intended to become a more general policy
> > analysis and generation backend, but never evolved that way, whereas
> > gui/sepolgen was the old name for Dan's policy generation script/tool
> > that is now just an alias for sepolicy generate. gui could be called
> > system-config-selinux, but then it can also be invoked as sepolicy gui.
> > It certainly started life as a Red Hat tool, but I'm not sure if anyone
> > else is using it.  Refactoring all of it, including
> > semanage/seobject.py, may make sense.

Okay this is roughly what I understood too so thats good. As things get
cleaned up more over time hopefully more gets ported to setools4 and
then we can start dropping the legacy parts. especially since the ones
before setools4 dont completely support policy format 30.
> > 
> >> 3) The deps of each of the bits is somewhat complicated to figure out.
> >> semodule-utils looks like it only needs libsepol and libselinux and the
> >> others look like they need most of the others? The makefile just builds
> >> them in order but i'd like to specify more accurate deps in the gentoo
> >> packages (especially external deps for each package) so they get
> >> (re)built as required as things update.
> > 
> > I was also trying to make it easy to omit the optional components
> > (OPT_SUBDIRS in the top-level Makefile), i.e. the ones that are not
> > required for operation.  I would omit at least dbus, gui, mcstrans,
> > restorecond, and sandbox by default from a base install.  python is
> > likely needed for general purpose distros but could be omitted from
> > embedded systems.  Actually, I don't see why semodule-utils components
> > are linking with libselinux; they do not include selinux.h or make any
> > calls to libselinux AFAICS, so I think that only truly depends on libsepol.
> 
> Fixed this too on the branch - removed the -lselinux from semodule-utils
> Makefiles.

Aha! thanks, I was just looking at the output of ldd and didnt
investigate too far.
> > 
> >> Also which of these are required to build refpolicy? the docs on that
> >> may need updating later too.
> > 
> > I would only expect libsepol, checkpolicy, and semodule-utils to be
> > needed to build refpolicy, while libsemanage and policycoreutils would
> > also be needed to install/load refpolicy.
> > 
> >> 4) mcstrans fails to build on my laptop, i'll send patches later. I
> >> might have stricter warnings on or something.
> > 
> > Ok, I already had to fix a number of such warnings for it when I
> > re-enabled building it by default on that branch (it was disabled
> > before), so not surprised - just send the patches our way.
> > 
> >> 5) in python/sepolicy/Makefile:
> >> override CFLAGS += -I$(PREFIX)/include -DPACKAGE="policycoreutils"
> >> should that be something instead of policycoreutils now?
> > 
> > Probably can be removed entirely.
> > 
> >> 6) we have a policycoreutils-extra thats been floating around as part of
> >> policycoreutils in gentoo. Mainly has rlpkg and selocal. After this
> >> split is as good a time as any to cleanup and upstream them.
> > 
> > Ok, in that case we might want to think about what else if anything
> > might go there.
> > 
> >> 7) I just noticed when looking through different Makefiles that some
> >> variables default to different things. I'll send patches for this too
> >> later once its merged in. Its nothing huge just better to be the same.
> >>
> >>> Note that the release script will add the selinux- prefix for dbus, gui,
> >>> python, and sandbox when generating the source tarballs so that they
> >>> have unique names suitable for source packages.
> >>
> >> This makes sense but I wonder if the name prefix is going to be annoying
> >> when we end up needing to backport a patch on a release since the paths
> >> would be different. But then again we've always had to edit them since
> >> they are one level down so I dont think I mind this minor extra bit too.
> > 
> > Open to suggestions; I could add the prefix in the source tree itself;
> > it just seemed ugly/unnecessary.  Or we could split up the repository
> > into multiple ones / submodules, but I'm not keen on that.

lets just keep it as-is, its hardly a big deal and there isnt anything
all that much better.

It all looks good to me currently. Cant think of anything else that
should be done before merging it in.

-- Jason

Re: [RFC] Split up policycoreutils

[Stephen Smalley]

On 11/15/2016 11:30 AM, Jason Zaman wrote:
> On Tue, Nov 15, 2016 at 10:01:12AM -0500, Stephen Smalley wrote:
>> On 11/15/2016 09:47 AM, Stephen Smalley wrote:
>>> On 11/14/2016 03:41 PM, Jason Zaman wrote:
>>>> These look pretty good to me. I have written most of the ebuilds for
>>>> gentoo for these new packages but have not committed to the tree yet.
>>>>
>>>> There are a couple issues:
>>>> 1) What is the license for each of the tarballs? there is no license or
>>>> COPYING file in the dirs.
>>>
>>> Fixed; I copied the policycoreutils/COPYING file into each of the new
>>> ones since they were all moved from policycoreutils.
>>>
>>>>
>>>> 2) even tho i fixed up a lot of it so shouldnt be, I am *super* confused
>>>> about sepolicy vs sepolgen. there are like 4 separate dirs with those
>>>> names and the sepolicy Makefile makes a symlink for sepolgen. And then
>>>> there is the gui and the non-gui part of them. python/sepolicy/* should
>>>> hopefully die soon as things fully move over to setools4. should gui/ be
>>>> called system-config-selinux? also is it a redhatism or does it also
>>>> apply to other distros?
>>>
>>> I also find this confusing; hopefully Dan (cc'd) can help clarify
>>> matters since he wrote most of this code.  I do know that the old
>>> sepolgen package (now python/sepolgen) was just a python module used as
>>> the backend for audit2allow and intended to become a more general policy
>>> analysis and generation backend, but never evolved that way, whereas
>>> gui/sepolgen was the old name for Dan's policy generation script/tool
>>> that is now just an alias for sepolicy generate. gui could be called
>>> system-config-selinux, but then it can also be invoked as sepolicy gui.
>>> It certainly started life as a Red Hat tool, but I'm not sure if anyone
>>> else is using it.  Refactoring all of it, including
>>> semanage/seobject.py, may make sense.
> 
> Okay this is roughly what I understood too so thats good. As things get
> cleaned up more over time hopefully more gets ported to setools4 and
> then we can start dropping the legacy parts. especially since the ones
> before setools4 dont completely support policy format 30.
>>>
>>>> 3) The deps of each of the bits is somewhat complicated to figure out.
>>>> semodule-utils looks like it only needs libsepol and libselinux and the
>>>> others look like they need most of the others? The makefile just builds
>>>> them in order but i'd like to specify more accurate deps in the gentoo
>>>> packages (especially external deps for each package) so they get
>>>> (re)built as required as things update.
>>>
>>> I was also trying to make it easy to omit the optional components
>>> (OPT_SUBDIRS in the top-level Makefile), i.e. the ones that are not
>>> required for operation.  I would omit at least dbus, gui, mcstrans,
>>> restorecond, and sandbox by default from a base install.  python is
>>> likely needed for general purpose distros but could be omitted from
>>> embedded systems.  Actually, I don't see why semodule-utils components
>>> are linking with libselinux; they do not include selinux.h or make any
>>> calls to libselinux AFAICS, so I think that only truly depends on libsepol.
>>
>> Fixed this too on the branch - removed the -lselinux from semodule-utils
>> Makefiles.
> 
> Aha! thanks, I was just looking at the output of ldd and didnt
> investigate too far.
>>>
>>>> Also which of these are required to build refpolicy? the docs on that
>>>> may need updating later too.
>>>
>>> I would only expect libsepol, checkpolicy, and semodule-utils to be
>>> needed to build refpolicy, while libsemanage and policycoreutils would
>>> also be needed to install/load refpolicy.
>>>
>>>> 4) mcstrans fails to build on my laptop, i'll send patches later. I
>>>> might have stricter warnings on or something.
>>>
>>> Ok, I already had to fix a number of such warnings for it when I
>>> re-enabled building it by default on that branch (it was disabled
>>> before), so not surprised - just send the patches our way.
>>>
>>>> 5) in python/sepolicy/Makefile:
>>>> override CFLAGS += -I$(PREFIX)/include -DPACKAGE="policycoreutils"
>>>> should that be something instead of policycoreutils now?
>>>
>>> Probably can be removed entirely.
>>>
>>>> 6) we have a policycoreutils-extra thats been floating around as part of
>>>> policycoreutils in gentoo. Mainly has rlpkg and selocal. After this
>>>> split is as good a time as any to cleanup and upstream them.
>>>
>>> Ok, in that case we might want to think about what else if anything
>>> might go there.
>>>
>>>> 7) I just noticed when looking through different Makefiles that some
>>>> variables default to different things. I'll send patches for this too
>>>> later once its merged in. Its nothing huge just better to be the same.
>>>>
>>>>> Note that the release script will add the selinux- prefix for dbus, gui,
>>>>> python, and sandbox when generating the source tarballs so that they
>>>>> have unique names suitable for source packages.
>>>>
>>>> This makes sense but I wonder if the name prefix is going to be annoying
>>>> when we end up needing to backport a patch on a release since the paths
>>>> would be different. But then again we've always had to edit them since
>>>> they are one level down so I dont think I mind this minor extra bit too.
>>>
>>> Open to suggestions; I could add the prefix in the source tree itself;
>>> it just seemed ugly/unnecessary.  Or we could split up the repository
>>> into multiple ones / submodules, but I'm not keen on that.
> 
> lets just keep it as-is, its hardly a big deal and there isnt anything
> all that much better.
> 
> It all looks good to me currently. Cant think of anything else that
> should be done before merging it in.

Ok, it is now merged to master, with the commit prior to the merge
tagged as "before_splitpolicycoreutils".

Re: [RFC] Split up policycoreutils

[Stephen Smalley]

On 11/16/2016 02:00 PM, Stephen Smalley wrote:
> On 11/15/2016 11:30 AM, Jason Zaman wrote:
>> On Tue, Nov 15, 2016 at 10:01:12AM -0500, Stephen Smalley wrote:
>>> On 11/15/2016 09:47 AM, Stephen Smalley wrote:
>>>> On 11/14/2016 03:41 PM, Jason Zaman wrote:
>>>>> These look pretty good to me. I have written most of the ebuilds for
>>>>> gentoo for these new packages but have not committed to the tree yet.
>>>>>
>>>>> There are a couple issues:
>>>>> 1) What is the license for each of the tarballs? there is no license or
>>>>> COPYING file in the dirs.
>>>>
>>>> Fixed; I copied the policycoreutils/COPYING file into each of the new
>>>> ones since they were all moved from policycoreutils.
>>>>
>>>>>
>>>>> 2) even tho i fixed up a lot of it so shouldnt be, I am *super* confused
>>>>> about sepolicy vs sepolgen. there are like 4 separate dirs with those
>>>>> names and the sepolicy Makefile makes a symlink for sepolgen. And then
>>>>> there is the gui and the non-gui part of them. python/sepolicy/* should
>>>>> hopefully die soon as things fully move over to setools4. should gui/ be
>>>>> called system-config-selinux? also is it a redhatism or does it also
>>>>> apply to other distros?
>>>>
>>>> I also find this confusing; hopefully Dan (cc'd) can help clarify
>>>> matters since he wrote most of this code.  I do know that the old
>>>> sepolgen package (now python/sepolgen) was just a python module used as
>>>> the backend for audit2allow and intended to become a more general policy
>>>> analysis and generation backend, but never evolved that way, whereas
>>>> gui/sepolgen was the old name for Dan's policy generation script/tool
>>>> that is now just an alias for sepolicy generate. gui could be called
>>>> system-config-selinux, but then it can also be invoked as sepolicy gui.
>>>> It certainly started life as a Red Hat tool, but I'm not sure if anyone
>>>> else is using it.  Refactoring all of it, including
>>>> semanage/seobject.py, may make sense.
>>
>> Okay this is roughly what I understood too so thats good. As things get
>> cleaned up more over time hopefully more gets ported to setools4 and
>> then we can start dropping the legacy parts. especially since the ones
>> before setools4 dont completely support policy format 30.
>>>>
>>>>> 3) The deps of each of the bits is somewhat complicated to figure out.
>>>>> semodule-utils looks like it only needs libsepol and libselinux and the
>>>>> others look like they need most of the others? The makefile just builds
>>>>> them in order but i'd like to specify more accurate deps in the gentoo
>>>>> packages (especially external deps for each package) so they get
>>>>> (re)built as required as things update.
>>>>
>>>> I was also trying to make it easy to omit the optional components
>>>> (OPT_SUBDIRS in the top-level Makefile), i.e. the ones that are not
>>>> required for operation.  I would omit at least dbus, gui, mcstrans,
>>>> restorecond, and sandbox by default from a base install.  python is
>>>> likely needed for general purpose distros but could be omitted from
>>>> embedded systems.  Actually, I don't see why semodule-utils components
>>>> are linking with libselinux; they do not include selinux.h or make any
>>>> calls to libselinux AFAICS, so I think that only truly depends on libsepol.
>>>
>>> Fixed this too on the branch - removed the -lselinux from semodule-utils
>>> Makefiles.
>>
>> Aha! thanks, I was just looking at the output of ldd and didnt
>> investigate too far.
>>>>
>>>>> Also which of these are required to build refpolicy? the docs on that
>>>>> may need updating later too.
>>>>
>>>> I would only expect libsepol, checkpolicy, and semodule-utils to be
>>>> needed to build refpolicy, while libsemanage and policycoreutils would
>>>> also be needed to install/load refpolicy.
>>>>
>>>>> 4) mcstrans fails to build on my laptop, i'll send patches later. I
>>>>> might have stricter warnings on or something.
>>>>
>>>> Ok, I already had to fix a number of such warnings for it when I
>>>> re-enabled building it by default on that branch (it was disabled
>>>> before), so not surprised - just send the patches our way.
>>>>
>>>>> 5) in python/sepolicy/Makefile:
>>>>> override CFLAGS += -I$(PREFIX)/include -DPACKAGE="policycoreutils"
>>>>> should that be something instead of policycoreutils now?
>>>>
>>>> Probably can be removed entirely.
>>>>
>>>>> 6) we have a policycoreutils-extra thats been floating around as part of
>>>>> policycoreutils in gentoo. Mainly has rlpkg and selocal. After this
>>>>> split is as good a time as any to cleanup and upstream them.
>>>>
>>>> Ok, in that case we might want to think about what else if anything
>>>> might go there.
>>>>
>>>>> 7) I just noticed when looking through different Makefiles that some
>>>>> variables default to different things. I'll send patches for this too
>>>>> later once its merged in. Its nothing huge just better to be the same.
>>>>>
>>>>>> Note that the release script will add the selinux- prefix for dbus, gui,
>>>>>> python, and sandbox when generating the source tarballs so that they
>>>>>> have unique names suitable for source packages.
>>>>>
>>>>> This makes sense but I wonder if the name prefix is going to be annoying
>>>>> when we end up needing to backport a patch on a release since the paths
>>>>> would be different. But then again we've always had to edit them since
>>>>> they are one level down so I dont think I mind this minor extra bit too.
>>>>
>>>> Open to suggestions; I could add the prefix in the source tree itself;
>>>> it just seemed ugly/unnecessary.  Or we could split up the repository
>>>> into multiple ones / submodules, but I'm not keen on that.
>>
>> lets just keep it as-is, its hardly a big deal and there isnt anything
>> all that much better.
>>
>> It all looks good to me currently. Cant think of anything else that
>> should be done before merging it in.
> 
> Ok, it is now merged to master, with the commit prior to the merge
> tagged as "before_splitpolicycoreutils".

And I dropped the ChangeLogs.  Can revive and update them if there is
demand.  Known unresolved issues:

- Need to split/update the policycoreutils/po files.  Not sure if there
is an easy way to do that.

- I didn't fix the extraneous CFLAGS override in
python/sepolicy/Makefile; we can do that whenever.

- We'll need to decide how to handle VERSIONs going forward, e.g. if
we'll keep them in sync across components or let each one only track
changes to that component.

Re: [RFC] Split up policycoreutils

[Daniel J Walsh]

On 11/15/2016 09:47 AM, Stephen Smalley wrote:
> On 11/14/2016 03:41 PM, Jason Zaman wrote:
>> These look pretty good to me. I have written most of the ebuilds for
>> gentoo for these new packages but have not committed to the tree yet.
>>
>> There are a couple issues:
>> 1) What is the license for each of the tarballs? there is no license or
>> COPYING file in the dirs.
> Fixed; I copied the policycoreutils/COPYING file into each of the new
> ones since they were all moved from policycoreutils.
>
>> 2) even tho i fixed up a lot of it so shouldnt be, I am *super* confused
>> about sepolicy vs sepolgen. there are like 4 separate dirs with those
>> names and the sepolicy Makefile makes a symlink for sepolgen. And then
>> there is the gui and the non-gui part of them. python/sepolicy/* should
>> hopefully die soon as things fully move over to setools4. should gui/ be
>> called system-config-selinux? also is it a redhatism or does it also
>> apply to other distros?
sepolicy is a big python library used to generate things like the man
pages and
all of the policy analyses tools.  The goal was to change seinfo and
sesearch output
into something more easily consumed by non SELinux experts.  sepolgen as
Stephen
said is just a link to sepolicy generate code which is used heavily for
generating policy
templates.  sepolicy libraries are used by the sepolicy command suite.
> I also find this confusing; hopefully Dan (cc'd) can help clarify
> matters since he wrote most of this code.  I do know that the old
> sepolgen package (now python/sepolgen) was just a python module used as
> the backend for audit2allow and intended to become a more general policy
> analysis and generation backend, but never evolved that way, whereas
> gui/sepolgen was the old name for Dan's policy generation script/tool
> that is now just an alias for sepolicy generate. gui could be called
> system-config-selinux, but then it can also be invoked as sepolicy gui.
> It certainly started life as a Red Hat tool, but I'm not sure if anyone
> else is using it.  Refactoring all of it, including
> semanage/seobject.py, may make sense.
>
>> 3) The deps of each of the bits is somewhat complicated to figure out.
>> semodule-utils looks like it only needs libsepol and libselinux and the
>> others look like they need most of the others? The makefile just builds
>> them in order but i'd like to specify more accurate deps in the gentoo
>> packages (especially external deps for each package) so they get
>> (re)built as required as things update.
> I was also trying to make it easy to omit the optional components
> (OPT_SUBDIRS in the top-level Makefile), i.e. the ones that are not
> required for operation.  I would omit at least dbus, gui, mcstrans,
> restorecond, and sandbox by default from a base install.  python is
> likely needed for general purpose distros but could be omitted from
> embedded systems.  Actually, I don't see why semodule-utils components
> are linking with libselinux; they do not include selinux.h or make any
> calls to libselinux AFAICS, so I think that only truly depends on libsepol.
>
>> Also which of these are required to build refpolicy? the docs on that
>> may need updating later too.
> I would only expect libsepol, checkpolicy, and semodule-utils to be
> needed to build refpolicy, while libsemanage and policycoreutils would
> also be needed to install/load refpolicy.
>
>> 4) mcstrans fails to build on my laptop, i'll send patches later. I
>> might have stricter warnings on or something.
> Ok, I already had to fix a number of such warnings for it when I
> re-enabled building it by default on that branch (it was disabled
> before), so not surprised - just send the patches our way.
>
>> 5) in python/sepolicy/Makefile:
>> override CFLAGS += -I$(PREFIX)/include -DPACKAGE="policycoreutils"
>> should that be something instead of policycoreutils now?
> Probably can be removed entirely.
>
>> 6) we have a policycoreutils-extra thats been floating around as part of
>> policycoreutils in gentoo. Mainly has rlpkg and selocal. After this
>> split is as good a time as any to cleanup and upstream them.
> Ok, in that case we might want to think about what else if anything
> might go there.
>
>> 7) I just noticed when looking through different Makefiles that some
>> variables default to different things. I'll send patches for this too
>> later once its merged in. Its nothing huge just better to be the same.
>>
>>> Note that the release script will add the selinux- prefix for dbus, gui,
>>> python, and sandbox when generating the source tarballs so that they
>>> have unique names suitable for source packages.
>> This makes sense but I wonder if the name prefix is going to be annoying
>> when we end up needing to backport a patch on a release since the paths
>> would be different. But then again we've always had to edit them since
>> they are one level down so I dont think I mind this minor extra bit too.
> Open to suggestions; I could add the prefix in the source tree itself;
> it just seemed ugly/unnecessary.  Or we could split up the repository
> into multiple ones / submodules, but I'm not keen on that.