[PATCH] add selpolgen

[PATCH] add selpolgen

[Karl MacMillan]

This is a patch (available for download because of size - see url below) 
to add a python library named selpolgen and a new version of audit2allow 
that uses this library. This is a minimally changed version of what I 
have been calling madison.

I am submitting this for inclusion as part of the main selinux 
distribution. I believe that inclusion here will help make good policy 
generation tools develop sooner and give a common base for creating new 
tools.

Questions:
* I have the library at the top-level of the project - like the C 
libraries. Is this the best location? What about the name?

* Should the old audit2allow be retained in any form? I've tried to make 
this a drop-in replacement, but there are likely regressions / changes. 
There are also a few options still missing that I will add soon.

Karl

http://people.redhat.com/kmacmill/patches/selinux/2007-01-16-selpolgen-initial-submission.patch.gz

  a/policycoreutils/audit2allow/avc.py          |  553
  b/policycoreutils/audit2allow/selpolgen-ifgen |   84
  b/selpolgen/HACKING                           |   79
  b/selpolgen/Makefile                          |   23
  b/selpolgen/TODO                              |   33
  b/selpolgen/VERSION                           |    1
  b/selpolgen/selpolgen/Makefile                |   12
  b/selpolgen/selpolgen/access.py               |  297
  b/selpolgen/selpolgen/audit.py                |  444
  b/selpolgen/selpolgen/classperms.py           |  116
  b/selpolgen/selpolgen/defaults.py             |   41
  b/selpolgen/selpolgen/interfaces.py           |  425
  b/selpolgen/selpolgen/lex.py                  |  712 +
  b/selpolgen/selpolgen/matching.py             |  254
  b/selpolgen/selpolgen/module.py               |  219
  b/selpolgen/selpolgen/objectmodel.py          |  172
  b/selpolgen/selpolgen/output.py               |  159
  b/selpolgen/selpolgen/policygen.py            |  344
  b/selpolgen/selpolgen/refparser.py            |  746 +
  b/selpolgen/selpolgen/refpolicy.py            |  727 +
  b/selpolgen/selpolgen/selpolgeni18n.py        |   26
  b/selpolgen/selpolgen/util.py                 |   87
  b/selpolgen/selpolgen/yacc.py                 | 2175 +++
  b/selpolgen/share/Makefile                    |    8
  b/selpolgen/share/perm_map                    |  993 +
  b/selpolgen/test_data/audit.log               | 5225 +++++++
  b/selpolgen/test_data/httpd.log               |10850 ++++++++++++++++
  b/selpolgen/test_data/short.log               |   15
  b/selpolgen/tests/Makefile                    |    8
  b/selpolgen/tests/audit.txt                   |  200
  b/selpolgen/tests/module_compile_test.te      |    8
  b/selpolgen/tests/perm_map                    |  993 +
  b/selpolgen/tests/run-tests.py                |   45
  b/selpolgen/tests/test_access.py              |  238
  b/selpolgen/tests/test_audit.py               |  151
  b/selpolgen/tests/test_interfaces.py          |  282
  b/selpolgen/tests/test_matching.py            |  144
  b/selpolgen/tests/test_module.py              |   35
  b/selpolgen/tests/test_objectmodel.py         |   44
  b/selpolgen/tests/test_policygen.py           |   31
  b/selpolgen/tests/test_refparser.py           |  120
  b/selpolgen/tests/test_refpolicy.py           |  164
  policycoreutils/audit2allow/Makefile          |   16
  policycoreutils/audit2allow/audit2allow       |  486
  44 files changed, 27000 insertions(+), 785 deletions(-)



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] add selpolgen

[Joshua Brindle]

Karl MacMillan wrote:
> This is a patch (available for download because of size - see url 
> below) to add a python library named selpolgen and a new version of 
> audit2allow that uses this library. This is a minimally changed 
> version of what I have been calling madison.
>
> I am submitting this for inclusion as part of the main selinux 
> distribution. I believe that inclusion here will help make good policy 
> generation tools develop sooner and give a common base for creating 
> new tools.
>
> Questions:
> * I have the library at the top-level of the project - like the C 
> libraries. Is this the best location? What about the name?
This doesn't seem like a good place, and the upstream selinux repo 
doesn't seem like a good dumping ground for all-things-selinux either, I 
don't know of a better way to spur community support though.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] add selpolgen

[Karl MacMillan]

On Tue, 2007-01-16 at 11:23 -0500, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > This is a patch (available for download because of size - see url 
> > below) to add a python library named selpolgen and a new version of 
> > audit2allow that uses this library. This is a minimally changed 
> > version of what I have been calling madison.
> >
> > I am submitting this for inclusion as part of the main selinux 
> > distribution. I believe that inclusion here will help make good policy 
> > generation tools develop sooner and give a common base for creating 
> > new tools.
> >
> > Questions:
> > * I have the library at the top-level of the project - like the C 
> > libraries. Is this the best location? What about the name?
> This doesn't seem like a good place, and the upstream selinux repo 
> doesn't seem like a good dumping ground for all-things-selinux either, I 
> don't know of a better way to spur community support though.
> 

This is certainly not dumping a random selinux-related project into the
upstream repo. If you look at the code there is:

1) A replacement for audit2allow - obviously this was deemed relevant at
some point so I don't see why an improved version would not still be
relevant.

2) A well-structured python library that includes many useful features
(parsing audit messages, creating / compiling modules, generating
selinux policy, etc.) with very little overlap to the other libraries
(the main overlap is parsing - which I am actively working on merging
with libsepol / checkpolicy).

I believe that what is added in 2 is truly generally useful for selinux
related applications. Additionally, by including this code I don't that
that upstream is automatically obligated to accept any new applications
based on this.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] add selpolgen

[Stephen Smalley]

On Tue, 2007-01-16 at 10:26 -0500, Karl MacMillan wrote:
> This is a patch (available for download because of size - see url below) 
> to add a python library named selpolgen and a new version of audit2allow 
> that uses this library. This is a minimally changed version of what I 
> have been calling madison.
> 
> I am submitting this for inclusion as part of the main selinux 
> distribution. I believe that inclusion here will help make good policy 
> generation tools develop sooner and give a common base for creating new 
> tools.
> 
> Questions:
> * I have the library at the top-level of the project - like the C 
> libraries. Is this the best location? What about the name?

The top-level location seems sane, but the naming and structure diverges
from the C libraries (e.g. one might expect a libsepolgen with man,
include, src, and tests subdirectories and ChangeLog, COPYING, Makefile,
and VERSION files).  I don't know what python libraries generally look
like.  selpolgen is also a bit confusing with MITRE's tool, although
that may not be important as it seems OBE.  You could just call it
libmadison unless there is a conflict.

> * Should the old audit2allow be retained in any form? I've tried to make 
> this a drop-in replacement, but there are likely regressions / changes. 
> There are also a few options still missing that I will add soon.

Unless there is a significant regression, I'd advocate just dropping the
old one (and also finally removing audit2allow.perl, the original perl
version that was moved aside when the python rewrite was merged).

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] add selpolgen

[Karl MacMillan]

Stephen Smalley wrote:
> On Tue, 2007-01-16 at 10:26 -0500, Karl MacMillan wrote:
>> This is a patch (available for download because of size - see url below) 
>> to add a python library named selpolgen and a new version of audit2allow 
>> that uses this library. This is a minimally changed version of what I 
>> have been calling madison.
>>
>> I am submitting this for inclusion as part of the main selinux 
>> distribution. I believe that inclusion here will help make good policy 
>> generation tools develop sooner and give a common base for creating new 
>> tools.
>>
>> Questions:
>> * I have the library at the top-level of the project - like the C 
>> libraries. Is this the best location? What about the name?
> 
> The top-level location seems sane, but the naming and structure diverges
> from the C libraries (e.g. one might expect a libsepolgen with man,
> include, src, and tests subdirectories and ChangeLog, COPYING, Makefile,
> and VERSION files).

* libsepolgen would not match python practice (this is a module not a 
library in python terms). I don't feel strongly either way, though, and 
the new patch changes this libselgen (see below).

* For python src / include are the same thing, which is why they are in 
a single directory. I put both the module directory and share under src.

* There shouldn't be man pages since doc strings and the built-in 
help(modulename) in python replace those (and the current code contains 
a fair amount of that documentation).

* I added a COPYING file and ChangeLog (empty for now).

* There is already a Makefile and VERSION and the Makefile follows the 
current conventions.

   I don't know what python libraries generally look
> like.  selpolgen is also a bit confusing with MITRE's tool, although
> that may not be important as it seems OBE.  You could just call it
> libmadison unless there is a conflict.
> 

I was trying to use a name that described its use without confusing it 
with polgen. What about 'selgen'? Any other ideas (I'd really prefer a 
meaningful name).

>> * Should the old audit2allow be retained in any form? I've tried to make 
>> this a drop-in replacement, but there are likely regressions / changes. 
>> There are also a few options still missing that I will add soon.
> 
> Unless there is a significant regression, I'd advocate just dropping the
> old one (and also finally removing audit2allow.perl, the original perl
> version that was moved aside when the python rewrite was merged).
> 

Ok. Updated patch can be found at 
http://people.redhat.com/kmacmill/patches/selinux/selgen-initial-submission.patch.gz

Karl

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] add selpolgen

[Stephen Smalley]

On Thu, 2007-01-18 at 14:53 -0500, Karl MacMillan wrote:
> Stephen Smalley wrote:
> > On Tue, 2007-01-16 at 10:26 -0500, Karl MacMillan wrote:
> >> This is a patch (available for download because of size - see url below) 
> >> to add a python library named selpolgen and a new version of audit2allow 
> >> that uses this library. This is a minimally changed version of what I 
> >> have been calling madison.
> >>
> >> I am submitting this for inclusion as part of the main selinux 
> >> distribution. I believe that inclusion here will help make good policy 
> >> generation tools develop sooner and give a common base for creating new 
> >> tools.
> >>
> >> Questions:
> >> * I have the library at the top-level of the project - like the C 
> >> libraries. Is this the best location? What about the name?
> > 
> > The top-level location seems sane, but the naming and structure diverges
> > from the C libraries (e.g. one might expect a libsepolgen with man,
> > include, src, and tests subdirectories and ChangeLog, COPYING, Makefile,
> > and VERSION files).
> 
> * libsepolgen would not match python practice (this is a module not a 
> library in python terms). I don't feel strongly either way, though, and 
> the new patch changes this libselgen (see below).

We can follow whatever practice is normal for python modules.  However,
how are those usually packaged?  Separate from the application that uses
them?  Or together?  As it stands, this module would become a dependency
of audit2allow and thus of policycoreutils; is there any benefit to
packaging it separately?

> I was trying to use a name that described its use without confusing it 
> with polgen. What about 'selgen'? Any other ideas (I'd really prefer a 
> meaningful name).

Not sure that is any less prone to confusion than selpolgen, and it
conveys less information about the purpose.  So I suppose selpolgen is
acceptable. 

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] add selpolgen

[Stephen Smalley]

On Fri, 2007-01-19 at 08:49 -0500, Stephen Smalley wrote:
> On Thu, 2007-01-18 at 14:53 -0500, Karl MacMillan wrote:
> > Stephen Smalley wrote:
> > > On Tue, 2007-01-16 at 10:26 -0500, Karl MacMillan wrote:
> > >> This is a patch (available for download because of size - see url below) 
> > >> to add a python library named selpolgen and a new version of audit2allow 
> > >> that uses this library. This is a minimally changed version of what I 
> > >> have been calling madison.
> > >>
> > >> I am submitting this for inclusion as part of the main selinux 
> > >> distribution. I believe that inclusion here will help make good policy 
> > >> generation tools develop sooner and give a common base for creating new 
> > >> tools.
> > >>
> > >> Questions:
> > >> * I have the library at the top-level of the project - like the C 
> > >> libraries. Is this the best location? What about the name?
> > > 
> > > The top-level location seems sane, but the naming and structure diverges
> > > from the C libraries (e.g. one might expect a libsepolgen with man,
> > > include, src, and tests subdirectories and ChangeLog, COPYING, Makefile,
> > > and VERSION files).
> > 
> > * libsepolgen would not match python practice (this is a module not a 
> > library in python terms). I don't feel strongly either way, though, and 
> > the new patch changes this libselgen (see below).
> 
> We can follow whatever practice is normal for python modules.  However,
> how are those usually packaged?  Separate from the application that uses
> them?  Or together?  As it stands, this module would become a dependency
> of audit2allow and thus of policycoreutils; is there any benefit to
> packaging it separately?

Or conversely, we could remove audit2allow from policycoreutils and put
it and this new python module into a single package.  It isn't as though
audit2allow is fundamental to system operation anyway.

> 
> > I was trying to use a name that described its use without confusing it 
> > with polgen. What about 'selgen'? Any other ideas (I'd really prefer a 
> > meaningful name).
> 
> Not sure that is any less prone to confusion than selpolgen, and it
> conveys less information about the purpose.  So I suppose selpolgen is
> acceptable. 

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] add selpolgen

[Karl MacMillan]

Stephen Smalley wrote:
> On Fri, 2007-01-19 at 08:49 -0500, Stephen Smalley wrote:
>> On Thu, 2007-01-18 at 14:53 -0500, Karl MacMillan wrote:
>>> Stephen Smalley wrote:
>> We can follow whatever practice is normal for python modules.  However,
>> how are those usually packaged?  Separate from the application that uses
>> them?  Or together?  As it stands, this module would become a dependency
>> of audit2allow and thus of policycoreutils; is there any benefit to
>> packaging it separately?
> 
> Or conversely, we could remove audit2allow from policycoreutils and put
> it and this new python module into a single package.  It isn't as though
> audit2allow is fundamental to system operation anyway.
> 

I think that the separation is desirable and matches current python 
practice. The sepolgen module is meant to be generic and available to 
many python programs (which is why it gets installed in python 
site-packages).

I would rather break policycoreutils into multiple packages to remove 
the dependency on this for minimal installations. There is a natural 
division between system / policy management tools (e.g., restorecon, 
semanage, newrole) and policy debugging / development (audit2allow, 
audit2why, semodule_link, semodule_expand, and semodule_package).

Maybe selcoreutils (which can eventually be bundled under a single 'sel' 
command like git / svn) and policydevtools. Distros may want to further 
divide those packages into graphical and non-graphical.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] add selpolgen

[Stephen Smalley]

On Fri, 2007-01-19 at 11:23 -0500, Karl MacMillan wrote:
> Stephen Smalley wrote:
> > On Fri, 2007-01-19 at 08:49 -0500, Stephen Smalley wrote:
> >> On Thu, 2007-01-18 at 14:53 -0500, Karl MacMillan wrote:
> >>> Stephen Smalley wrote:
> >> We can follow whatever practice is normal for python modules.  However,
> >> how are those usually packaged?  Separate from the application that uses
> >> them?  Or together?  As it stands, this module would become a dependency
> >> of audit2allow and thus of policycoreutils; is there any benefit to
> >> packaging it separately?
> > 
> > Or conversely, we could remove audit2allow from policycoreutils and put
> > it and this new python module into a single package.  It isn't as though
> > audit2allow is fundamental to system operation anyway.
> > 
> 
> I think that the separation is desirable and matches current python 
> practice. The sepolgen module is meant to be generic and available to 
> many python programs (which is why it gets installed in python 
> site-packages).

Ok.

> I would rather break policycoreutils into multiple packages to remove 
> the dependency on this for minimal installations. There is a natural 
> division between system / policy management tools (e.g., restorecon, 
> semanage, newrole) and policy debugging / development (audit2allow, 
> audit2why, semodule_link, semodule_expand, and semodule_package).
> 
> Maybe selcoreutils (which can eventually be bundled under a single 'sel' 
> command like git / svn) and policydevtools. Distros may want to further 
> divide those packages into graphical and non-graphical.

Are you proposing a new upstream structure, or just how the existing
policycoreutils might be split into multiple packages by distributions?
Fedora already splits newrole and system-config-selinux into their own
distinct sub-packages (policycoreutils-newrole, policycoreutils-gui),
the former to avoid a need for newrole under targeted policy due to
concerns about its suidness.

I'd tend to put semodule_package into the same class as
checkmodule/checkpolicy (policy build toolchain, required even to build
local modules, and thus needed by ordinary users), whereas
semodule_link, semodule_expand, and semodule_deps are more
development/debug tools oriented toward selinux developers.  audit2allow
and audit2why are likewise user-oriented tools rather than only being
used by selinux developers.

libsemanage invokes setfiles, genhomedircon, and load_policy, so it
requires them.  There is presently a circular dependency between
libsemanage and genhomedircon.

semanage, semodule, and setsebool all fall into the same class as policy
management tools.  They depend on libsemanage, so they bring in its
dependencies.

restorecon, setfiles, restorecond, and fixfiles all fall into the same
class as filesystem labeling tools.  Reconciling restorecon and setfiles
would be nice, as they significantly overlap in functionality and
primarily differ in default user interface.

newrole and run_init are user-oriented tools that are presently only
needed/useful under strict and mls policies, although that may change in
the future if targeted grows support for user roles.  

secon is user-oriented but not required for operation.  sestatus is
support-oriented and not required for operation.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] add selpolgen

[Karl MacMillan]

Stephen Smalley wrote:
> On Fri, 2007-01-19 at 11:23 -0500, Karl MacMillan wrote:
>> Stephen Smalley wrote:
>>> On Fri, 2007-01-19 at 08:49 -0500, Stephen Smalley wrote:
>>>> On Thu, 2007-01-18 at 14:53 -0500, Karl MacMillan wrote:
>>>>> Stephen Smalley wrote:
>>>> We can follow whatever practice is normal for python modules.  However,
>>>> how are those usually packaged?  Separate from the application that uses
>>>> them?  Or together?  As it stands, this module would become a dependency
>>>> of audit2allow and thus of policycoreutils; is there any benefit to
>>>> packaging it separately?
>>> Or conversely, we could remove audit2allow from policycoreutils and put
>>> it and this new python module into a single package.  It isn't as though
>>> audit2allow is fundamental to system operation anyway.
>>>
>> I think that the separation is desirable and matches current python 
>> practice. The sepolgen module is meant to be generic and available to 
>> many python programs (which is why it gets installed in python 
>> site-packages).
> 
> Ok.
> 
>> I would rather break policycoreutils into multiple packages to remove 
>> the dependency on this for minimal installations. There is a natural 
>> division between system / policy management tools (e.g., restorecon, 
>> semanage, newrole) and policy debugging / development (audit2allow, 
>> audit2why, semodule_link, semodule_expand, and semodule_package).
>>
>> Maybe selcoreutils (which can eventually be bundled under a single 'sel' 
>> command like git / svn) and policydevtools. Distros may want to further 
>> divide those packages into graphical and non-graphical.
> 
> Are you proposing a new upstream structure, or just how the existing
> policycoreutils might be split into multiple packages by distributions?
> Fedora already splits newrole and system-config-selinux into their own
> distinct sub-packages (policycoreutils-newrole, policycoreutils-gui),
> the former to avoid a need for newrole under targeted policy due to
> concerns about its suidness.
> 

New upstream structure - though just letting distros split them how they 
will is also fine with me.

> I'd tend to put semodule_package into the same class as
> checkmodule/checkpolicy (policy build toolchain, required even to build
> local modules, and thus needed by ordinary users), whereas
> semodule_link, semodule_expand, and semodule_deps are more
> development/debug tools oriented toward selinux developers.  audit2allow
> and audit2why are likewise user-oriented tools rather than only being
> used by selinux developers.
> 

Agreed.

> libsemanage invokes setfiles, genhomedircon, and load_policy, so it
> requires them.  There is presently a circular dependency between
> libsemanage and genhomedircon.
> 

genhomedircon should probably be folded into libsemanage eventually.

Karl

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] add selpolgen

[Stephen Smalley]

On Fri, 2007-01-19 at 11:59 -0500, Stephen Smalley wrote:
> On Fri, 2007-01-19 at 11:23 -0500, Karl MacMillan wrote:
> > Stephen Smalley wrote:
> > > On Fri, 2007-01-19 at 08:49 -0500, Stephen Smalley wrote:
> > >> On Thu, 2007-01-18 at 14:53 -0500, Karl MacMillan wrote:
> > >>> Stephen Smalley wrote:
> > >> We can follow whatever practice is normal for python modules.  However,
> > >> how are those usually packaged?  Separate from the application that uses
> > >> them?  Or together?  As it stands, this module would become a dependency
> > >> of audit2allow and thus of policycoreutils; is there any benefit to
> > >> packaging it separately?
> > > 
> > > Or conversely, we could remove audit2allow from policycoreutils and put
> > > it and this new python module into a single package.  It isn't as though
> > > audit2allow is fundamental to system operation anyway.
> > > 
> > 
> > I think that the separation is desirable and matches current python 
> > practice. The sepolgen module is meant to be generic and available to 
> > many python programs (which is why it gets installed in python 
> > site-packages).
> 
> Ok.
> 
> > I would rather break policycoreutils into multiple packages to remove 
> > the dependency on this for minimal installations. There is a natural 
> > division between system / policy management tools (e.g., restorecon, 
> > semanage, newrole) and policy debugging / development (audit2allow, 
> > audit2why, semodule_link, semodule_expand, and semodule_package).
> > 
> > Maybe selcoreutils (which can eventually be bundled under a single 'sel' 
> > command like git / svn) and policydevtools. Distros may want to further 
> > divide those packages into graphical and non-graphical.
> 
> Are you proposing a new upstream structure, or just how the existing
> policycoreutils might be split into multiple packages by distributions?
> Fedora already splits newrole and system-config-selinux into their own
> distinct sub-packages (policycoreutils-newrole, policycoreutils-gui),
> the former to avoid a need for newrole under targeted policy due to
> concerns about its suidness.
> 
> I'd tend to put semodule_package into the same class as
> checkmodule/checkpolicy (policy build toolchain, required even to build
> local modules, and thus needed by ordinary users), whereas
> semodule_link, semodule_expand, and semodule_deps are more
> development/debug tools oriented toward selinux developers.  audit2allow
> and audit2why are likewise user-oriented tools rather than only being
> used by selinux developers.

Looks like there is a false dependency being created in the current
semodule_*/ Makefiles on libselinux, when those tools only require
libsepol (unlike the base semodule utility) just like checkpolicy.
Originally policycoreutils was only utilities that required selinux to
run, and checkpolicy was kept separate due to its independence from the
runtime.  So we could even move all of the semodule_* utils under
checkpolicy.

> libsemanage invokes setfiles, genhomedircon, and load_policy, so it
> requires them.  There is presently a circular dependency between
> libsemanage and genhomedircon.
> 
> semanage, semodule, and setsebool all fall into the same class as policy
> management tools.  They depend on libsemanage, so they bring in its
> dependencies.
> 
> restorecon, setfiles, restorecond, and fixfiles all fall into the same
> class as filesystem labeling tools.  Reconciling restorecon and setfiles
> would be nice, as they significantly overlap in functionality and
> primarily differ in default user interface.
> 
> newrole and run_init are user-oriented tools that are presently only
> needed/useful under strict and mls policies, although that may change in
> the future if targeted grows support for user roles.  
> 
> secon is user-oriented but not required for operation.  sestatus is
> support-oriented and not required for operation.
> 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.