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 

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 

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 

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.
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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

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)
* 

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 

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

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC] Split up policycoreutils

[Dominick Grift]

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-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
> 


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



signature.asc
Description: OpenPGP digital signature

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.

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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


___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC] Split up policycoreutils

[Sven Vermeulen]

On Oct 24, 2016 3:19 PM, "Stephen Smalley"  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
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC] Split up policycoreutils

[Dominick Grift]

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-le...@tycho.nsa.gov.
>> To get help, send an email containing "help" to 
>> selinux-requ...@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-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
> 


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



signature.asc
Description: OpenPGP digital signature
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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.


___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC] Split up policycoreutils

[Dominick Grift]

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-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
> 


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



signature.asc
Description: OpenPGP digital signature
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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.


___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC] Split up policycoreutils

[Sven Vermeulen]

On Fri, Oct 21, 2016 at 7:47 PM, 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).
[... 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
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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






___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC] Split up policycoreutils

[Paul Moore]

On Fri, Oct 21, 2016 at 2:11 PM, Daniel J Walsh  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
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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

[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?
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.