Re: MLS dominance check behavior on el7
On 10/04/2018 05:01 PM, Stephen Smalley wrote:
On 09/30/2018 10:43 AM, Chris PeBenito wrote:
On 09/11/2018 04:20 PM, Stephen Smalley wrote:
On 09/11/2018 03:04 PM, Joe Nall wrote:
On Sep 11, 2018, at 1:29 PM, Stephen Smalley
On 09/11/2018 10:41 AM, Stephen Smalley wrote:
On 09/10/2018 06:30 PM, Ted Toth wrote:
BTW, I noticed there is another permission ("translate") defined in
the context class and its constraint is ((h1 dom h2) or (t1 ==
mlstranslate)). I would have guessed that it was intended as a
front-end service check over what processes could request context
translations from mcstrans or what contexts they could translate,
but I don't see it being used in mcstrans anywhere. Is this a
legacy thing from early setransd/mcstransd days? There is a TODO
comment in mcstrans process_request() that suggests there was an
intent to perform a dominance check between the requester context
and the specified context, but that's not implemented. Appears to
be allowed in current policy for all domains to the setrans_t
domain itself.
I think 'translate' predates my mcstransd work and dates from the
original TCS implementation. There is an argument to implement that
constraint, but we've been operating without it for so long it does
not seem worthwhile.
Well, I guess we ought to either implement it or delete the
permission definition from refpolicy.
I'm fine removing it. It's just the translate permission that is
unused, not the whole class, correct?
Correct. Only caveat is that removing translate will change the
permission index of contains, which could break a running mcstransd upon
a policy reload (doesn't use selinux_check_access or even the avc; won't
flush the class/perm string mapping on a reload automatically).
Good point. I think I'll remove all the rules and constraints and then
rename the permission to unused or unused_perm. Then the indices will
be stable, but it will be clear the perm is unused.
--
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: [PATCH] libsemanage: improve semanage_migrate_store import failure
On 10/05/2018 10:32 AM, Jason Zaman wrote:
On Fri, Oct 05, 2018 at 07:13:23AM -0700, William Roberts wrote:
On Thu, Oct 4, 2018 at 12:46 PM Yuli Khodorkovskiy <
yuli.khodorkovs...@crunchydata.com> wrote:
The python module import error in semanage_migrate_store was misleading.
Before, it would print that the module is not installed, even though
it is in fact on the system.
Now the python module import failure is correctly reported if the module
is not installed or the exact reason for failure is reported to the user.
Signed-off-by: Yuli Khodorkovskiy
---
libsemanage/utils/semanage_migrate_store | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libsemanage/utils/semanage_migrate_store
b/libsemanage/utils/semanage_migrate_store
index 2e6cb278..50eb59ef 100755
--- a/libsemanage/utils/semanage_migrate_store
+++ b/libsemanage/utils/semanage_migrate_store
@@ -15,10 +15,12 @@ sepol = ctypes.cdll.LoadLibrary('libsepol.so.1')
try:
import selinux
import semanage
-except:
+except ImportError:
print("You must install libselinux-python and libsemanage-python
before running this tool", file=sys.stderr)
exit(1)
-
+except Exception as e:
+ print("Failed to import libselinux-python/libsemanage-python: %s"
% str(e))
+ exit(1)
We should really only be handling exceptions we reasonably expect and
discourage
the usage of catching raw Exception, especially considering not-catching
this will
cause the runtime to print a stack trace, the error and exit non-zero.
We probably only need the except ImportError change and can drop the second
hunk.
Does anyone disagree with this?
For this case, I agree that ImportError is the only thing that should be
caught.
Agreed. catching Exception is bad cuz it also catches KeyboardInterrupt
and stuff like that.
That's not correct. Catching BaseException would catch
KeyboardInterrupt. Catching Exception would not. See the Python
builtin exception hierarchy:
https://docs.python.org/3/library/exceptions.html#exception-hierarchy
IMO catching Exception has valid uses.
--
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: MLS dominance check behavior on el7
On 09/11/2018 04:20 PM, Stephen Smalley wrote:
On 09/11/2018 03:04 PM, Joe Nall wrote:
On Sep 11, 2018, at 1:29 PM, Stephen Smalley wrote:
On 09/11/2018 10:41 AM, Stephen Smalley wrote:
On 09/10/2018 06:30 PM, Ted Toth wrote:
mcstrans mcscolor.c also uses the same logic I'd been using to
check dominance so this too will no longer function as expected on
el7. Do you any suggestions for doing a 'generic' (one not tied to
a specific resource class) dominance check in lieu of context
contains?
You should probably define your own permission with its own
constraint to avoid depending on the base policy's particular
constraint definitions. Certainly for your own code. For mcstrans,
mcscolor probably ought to be switched to using at least a separate
permission in the context class if not its own class to avoid
overloading the meaning with pam_selinux's usage (or vice versa, but
likely harder to change pam_selinux at this point).
It is possible to define an entirely new class, its permissions, and
its mls constraints via a CIL module IIUC, without needing to change
the base policy.
I don't think you can add a permission to an existing class via a
CIL module currently, unfortunately, so you can't just extend the
context class without modifying the base policy. So it may be
easier to define an entirely new class.
The class and permission ought to be specific to the usage. For
example, mcstrans could have its own class (mcstrans) with its own
permissions (e.g. color_match or color_use or ...) that abstract
away the logical check being performed. Dominance checks performed
for different reasons ought to use different permissions so that one
can distinguish what TE pairs are allowed them.
Your code could likewise define and use its own class and permission.
Does that make sense?
BTW, I noticed there is another permission ("translate") defined in
the context class and its constraint is ((h1 dom h2) or (t1 ==
mlstranslate)). I would have guessed that it was intended as a
front-end service check over what processes could request context
translations from mcstrans or what contexts they could translate, but
I don't see it being used in mcstrans anywhere. Is this a legacy
thing from early setransd/mcstransd days? There is a TODO comment in
mcstrans process_request() that suggests there was an intent to
perform a dominance check between the requester context and the
specified context, but that's not implemented. Appears to be allowed
in current policy for all domains to the setrans_t domain itself.
I think 'translate' predates my mcstransd work and dates from the
original TCS implementation. There is an argument to implement that
constraint, but we've been operating without it for so long it does
not seem worthwhile.
Well, I guess we ought to either implement it or delete the permission
definition from refpolicy.
I'm fine removing it. It's just the translate permission that is
unused, not the whole class, correct?
--
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.
ANN: SETools 4.2.0-rc
An SETools 4.2.0 release candidate is now available: https://github.com/SELinuxProject/setools/releases/tag/4.2.0-rc Changes since v4.2.0-beta: * Fixed performance regressions. * Made further memory usage improvements. * Fixed build issues with clean target and runtime_library_dirs. * Revised package structure to make policyrep a module of the setools package. * Symbol names are now available as the name attribute (e.g. Boolean.name, Type.name, etc.) * Fixed some apol layouts to increase the size of text fields. * Move constraint expression to its own class. * Made Conditional.evaluate() more useful and added BaseTERule.enabled() method to determine if a rule is enabled. Changes since v4.1.1: * Replaced the Python/SWIG/static-linked-libsepol policyrep module with a Cython implementation. This will have performance and memory-usage improvements and breaks the static linking to libsepol. * Significant memory usage reduction in sediff (approximately 60%, depending on the policies). * Added support for SCTP portcons * Updated permission maps This release of SETools has changed dependencies since 4.1.1. See README.md for more details. -- 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.
ANN: SETools 4.2.0-beta
An SETools 4.2.0-beta release is now available: https://github.com/SELinuxProject/setools/releases/tag/4.2.0-beta Changes since v4.1.1: * Replaced the Python/SWIG/static-linked-libsepol policyrep module with a Cython implementation. This will have performance and memory-usage improvements and breaks the static linking to libsepol. * Significant memory usage reduction in sediff (approximately 60%, depending on the policies). * Added support for SCTP portcons * Updated permission maps This release of SETools has changed dependencies since 4.1.1. See README.md for more details. -- 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.
ANN: Reference Policy release
In this release, the refpolicy and refpolicy-contrib repositories were remerged; the modules were moved out of the contrib layer. It also includes a large update for the X Desktop Group base directory specification and SCTP support, among various other fixes. Refpolicy now requires SELinux userspace v2.8 to compile. <https://github.com/SELinuxProject/refpolicy/releases/tag/RELEASE_2_20180701> -- 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.
ANN: Reference Policy repo move
The Reference Policy repository moved. It is now available on the SELinuxProject GitHub project: https://github.com/SELinuxProject/refpolicy In the process of moving, the contrib submodule was removed and its contents were moved back into the main repository. -- 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.
ANN: SETools repo move
The SETools repository moved. It is now available on the SELinuxProject GitHub project: https://github.com/SELinuxProject/setools If you are following the master branch, there are significant changes: * Replaced the Python/SWIG/static-linked-libsepol policyrep module with a Cython implementation. This will have performance and memory-usage improvements and breaks the static linking to libsepol. * Significant memory usage reduction in sediff (approximately 60%, depending on the policies). These will be the main changes for the next SETools release. -- 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: [PATCH] setools: Add sctp portcon support
On 03/20/2018 01:49 PM, Richard Haines via Selinux wrote:
Allow setools to interpret SCTP portcon policy statements
Signed-off-by: Richard Haines <richard_c_hai...@btinternet.com>
---
libqpol/policy_define.c | 2 ++
setools/policyrep/netcontext.py | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/libqpol/policy_define.c b/libqpol/policy_define.c
index dcc69fc..bffe451 100644
--- a/libqpol/policy_define.c
+++ b/libqpol/policy_define.c
@@ -4933,6 +4933,8 @@ int define_port_context(unsigned int low, unsigned int
high)
protocol = IPPROTO_UDP;
} else if ((strcmp(id, "dccp") == 0) || (strcmp(id, "DCCP") == 0)) {
protocol = IPPROTO_DCCP;
+ } else if ((strcmp(id, "sctp") == 0) || (strcmp(id, "SCTP") == 0)) {
+ protocol = IPPROTO_SCTP;
} else {
yyerror2("unrecognized protocol %s", id);
goto bad;
diff --git a/setools/policyrep/netcontext.py b/setools/policyrep/netcontext.py
index c7076d2..1793677 100644
--- a/setools/policyrep/netcontext.py
+++ b/setools/policyrep/netcontext.py
@@ -17,7 +17,7 @@
# License along with SETools. If not, see
# <http://www.gnu.org/licenses/>.
#
-from socket import AF_INET, AF_INET6, IPPROTO_TCP, IPPROTO_UDP, getprotobyname
+from socket import AF_INET, AF_INET6, IPPROTO_TCP, IPPROTO_UDP, IPPROTO_SCTP,
getprotobyname
from collections import namedtuple
from ipaddress import ip_address, ip_network
@@ -196,6 +196,7 @@ class PortconProtocol(int, PolicyEnum):
tcp = IPPROTO_TCP
udp = IPPROTO_UDP
dccp = IPPROTO_DCCP
+sctp = IPPROTO_SCTP
class Portcon(NetContext):
Thanks for the patch, but I'm reimplementing the SETools policyrep, so
I've added the equivalent support already.
--
Chris PeBenito
libsepol policycap names
I've been able to make SETools dynamically link to libsepol. However, one challenge is with policycap names. They're static libsepol, with nothing that exports them. Can we either: * export the sepol_polcap_getname() function, or * move the polcap_names[] in polcaps.c into ? Then I can avoid having to manually keep a polcap name list inside SETools. -- Chris PeBenito
Re: ANN: Reference Policy 2.20180114
On 01/16/2018 11:02 AM, Stephen Smalley wrote: On Sun, 2018-01-14 at 15:02 -0500, Chris PeBenito via refpolicy wrote: A new release, 2.20180114, of the SELinux Reference Policy is now available on the GitHub site: https://github.com/TresysTechnology/refpolicy/wiki/DownloadRelease Could we get the nnp_nosuid_transition policy capability enabled in the next release? That's my mistake; I should have enabled it in this release. Enabled in master now. -- Chris PeBenito
SETools source policy support will be dropped
I've been doing some reworking of SETools' policy representation library. I'm planning to remove SETools' support for loading source policies (policy.conf). There are reasons to do this; first, the SETools code includes a portion of the compiler toolchain to do the compiling in memory. Removing that will reduce the maintenance burden for keeping that code in sync and also reduce the SETools code size. It will also ensure that there are no errors introduced by SETools' compilation of the policy sources. Additionally, it should break the SETools static linking requirement, so SETools doesn't need to be recompiled every time a new libsepol is released. I don't think this will impact many, but let me know if this is a severe problem. -- Chris PeBenito
ANN: Reference Policy 2.20180114
A new release, 2.20180114, of the SELinux Reference Policy is now available on the GitHub site: https://github.com/TresysTechnology/refpolicy/wiki/DownloadRelease -- Chris PeBenito
Re: [PATCH 1/1] networkmanager: Grant access to unlabeled PKeys
On 11/27/2017 05:50 PM, Paul Moore wrote: On Mon, Nov 27, 2017 at 3:04 PM, Daniel Jurgens <dani...@mellanox.com> wrote: On 11/27/2017 10:19 AM, Paul Moore wrote: On Mon, Nov 27, 2017 at 9:03 AM, Dan Jurgens <dani...@mellanox.com> wrote: From: Daniel Jurgens <dani...@mellanox.com> For controlling IPoIB VLANs Reported-by: Honggang LI <ho...@redhat.com> Signed-off-by: Daniel Jurgens <dani...@mellanox.com> Tested-by: Honggang LI <ho...@redhat.com> --- networkmanager.te |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) [NOTE: resending due to a typo in the refpol mailing list address] We obviously need something like this now so we don't break IPoIB, but I wonder if we should make the IB access controls dynamic like the per-packet network access controls. We could key off the presence of the IB pkey and endport definitions: if there are any objects defined in the loaded policy we enable the controls, otherwise we disable them. I think I understand what you're saying Paul, but I'm not clear on the mechanism. Are you referring to the netlabel/IPSEC enable checks? They are wrapped up in selinux_peerlbl_enabled. Basically, yes. We could add a new variable/function that gates the access control checks in selinux_ib_pkey_access() and selinux_ib_endport_manage_subnet(); the checks would be enabled when there was Infiniband configuration loaded with the policy. Without the IB config loaded, all the checks would end up being just a domain check against unlabeled_t, which isn't very interesting, so we would just drop the checks. As long as it also respects policycap always_check_network, it works for me. -- Chris PeBenito
Re: Userspace Python version
On 09/13/2017 11:10 PM, Jason Zaman wrote:
On Sun, Sep 10, 2017 at 08:06:28PM +0200, Nicolas Iooss wrote:
On Sat, Sep 9, 2017 at 1:18 AM, Chris PeBenito <peben...@ieee.org> wrote:
I believe that all major SELinux distributions have at least Python 3.4
support. Python 3 changeover has gone so long that even 3.3 is about to go
end-of-life [1]. Can we officially drop Python 2.7 support in userspace
code?
I'd like to drop support for everything older than Python 3.4 in SETools.
[1]
http://blog.python.org/2017/09/python-337rc1-is-now-available-prior-to.html
When I updated the Arch Linux packages for the last release, I tried
to use Python 3 everywhere and there was one component which required
Python 2: selinux-gui [1], because PyGtk is not compatible with Python
3. After a quick search I found https://askubuntu.com/a/97107 : "PyGTK
has been deprecated in favor of PyGI+GTK. Because of that, a version
of PyGTK for Python 3 was never written."
I will try to port selinux-gui to PyGI [2] in order to reduce the
dependency towards Python 2. Before I start this work, are there
already other people working on this? More precisely there have been
some patches/commits related to this, like 9a57996dfa9a ("sandbox: Use
GObject introspection binding instead of pygtk2") and 917f398d7cd2
("policycoreutils: Use GObject introspection binding instead of
python-gobject in selinux_server.py") and I am wondering whether their
authors also looked at selinux-gui (and command
system-config-selinux).
Cheers,
Nicolas
[1] directory gui/ of https://github.com/SELinuxProject/selinux
[2] with ideas from
https://wiki.gnome.org/action/show/Projects/PyGObject/IntrospectionPorting
This sounds about right. I know for sure all the commandline and
important selinux stuff all works with python3. I dont really use
selinux-gui. I didnt port it over when i did the big 2to3 patches since
I dont really know gtk. I think some of the redhat guys did some fixes
for it but not sure how comprehensive.
I have a mild preference for porting that to py3 before dropping it but
I havent heard any issues on the gentoo side about py3 support since the
last release so its probably fine.
Can the one that drops py2 be version 4.2? then if there do happen to be
any small bugfixes they can continue on 4.1.x?
That was my plan, as I want to use a few py3-specific features finally.
--
Chris PeBenito
Userspace Python version
I believe that all major SELinux distributions have at least Python 3.4 support. Python 3 changeover has gone so long that even 3.3 is about to go end-of-life [1]. Can we officially drop Python 2.7 support in userspace code? I'd like to drop support for everything older than Python 3.4 in SETools. [1] http://blog.python.org/2017/09/python-337rc1-is-now-available-prior-to.html -- Chris PeBenito
ANN: SETools 4.1.1
I'm pleased to announce the SETools 4.1.1 release, available here: https://github.com/TresysTechnology/setools/releases/tag/4.1.1 There were three changes since 4.1.0: * SETools now requires libsepol 2.7. * Update to permission maps * Fixes for apol help files -- Chris PeBenito
ANN: Reference Policy 2.20170805
A new release, 2.20170805, of the SELinux Reference Policy is now available on the GitHub site: https://github.com/TresysTechnology/refpolicy/wiki/DownloadRelease This release has a significant amount of systemd work. The full changelog is too long to include in this email, so here's the diffstat instead: Core: 147 files changed, 5558 insertions(+), 1409 deletions(-) Contrib: 571 files changed, 4511 insertions(+), 1284 deletions(-) -- Chris PeBenito
Re: [PATCH] selinux: Generalize support for NNP/nosuid SELinux domain transitions
On 07/20/2017 09:04 AM, Stephen Smalley wrote: On Wed, 2017-07-19 at 21:17 -0400, Chris PeBenito wrote: On 07/19/2017 05:31 PM, Dominick Grift wrote: On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote: On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote: On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote: Once this permission is implemented I'll likely add the permission across most if not all transitions out of systemd. Yes but do not expect that to ,always, be enough due to the inheritance aspect. A process may have inherited the NNP flag, not because its started by systemd but because its started by a process that inherited the NNP flag because it was started by systemd. That just makes me want to apply the permission to all transitions for all domains. Not that I'm planning to do it in refpolicy. I'm definitely inclined to be very liberal in applying the permission in refpolicy. For my personal systems, I'd probably do an: allow domain domain:process nnp_nosuid_transition; so I don't ever have to think about it again. Caveats: 1. It would mean that transitions on any removable media would be possible, even when marked nosuid. So, for example, if you were to mount (or have auto-mounted) removable media with nosuid but without noexec, and the removable media had been maliciously crafted with a file with an entrypoint type, then a user could use it to transition to a potentially more privileged SELinux domain, even though it could not gain capabilities or uid-0 that way (or, if the user can induce another process to execute from this filesystem, then this could produce a domain transition that would normally have been prevented). Ditto for network filesystems. This is perhaps an argument for introducing a separate check on nosuid; could be done via a file-based additional check (Can domain D nosuid_transition on file type T?) in addition to the nnp_nosuid_transition process-based permission check or by adding a process2 class and splitting nnp_nosuid_transition into nosuid_transition and nnp_transition process-based permissions. This is a good point; however, if you're trusting removable media to do transitions on, you're already accepting a lot of risk of shooting yourself in the foot. While I understand the logic of the nosuid fs behavior, it's always bugged me because it's not obvious to most people. 2. It would mean that all domains could enable NNP, install seccomp filters (allowed for unprivileged processes if NNP is enabled), and execve a domain-changing program with those filters in effect, which could potentially lead to subverting the new domain. It is exactly for To make sure I understand, by subvert you mean the child domain would malfunction because of having less perms than required? this reason that domain transitions under NNP were originally not allowed, and then only allowed for bounded transitions. Also note that NNP is intended to be used to open up other previously unsafe actions for unprivileged processes, so this could be extended to more than just seccomp in the future (examples given in the past have included chroot, certain unshare/clone flags, etc, although it seems like some of this has been obsoleted/replaced by user namespaces). So from a safety POV, you really only want to allow this when the calling domain is more trusted than the callee domain; think of it as being similar (but not equivalent) to noatsecure and/or dyntransition. Perhaps then the permission should be named something like nnp_nosuid_inh or inherit_nnp_nosuid or some variation thereof? -- Chris PeBenito
[SUSPICIOUS MESSAGE] Re: [SUSPECTED SPAM] [SUSPICIOUS MESSAGE] Re: [PATCH] selinux: Generalize support for NNP/nosuid SELinux domain transitions
On 07/19/2017 05:31 PM, Dominick Grift wrote: On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote: On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote: On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote: On 07/18/2017 05:26 PM, Paul Moore wrote: On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote: On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote: On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <ja...@perfinion.com> wrote: ... Why do we want to disallow type-bounds to work even with the capability? it seems sensible to me to allow typebounds to transition even in the future. If we do then we probably dont need the policycap which seems less complicated. The suggestion to continue to support bounded domain transitions seems reasonable to me, although we would need to worry about which check to do first (bounded transition or process:nnp_nosuid_transition), and how to limit the auditing/reporting so admins are confused by the first check failing, yet the transition still taking place. None of these are unsolvable problems, but it will likely need a bit more work. I'm sure Stephen has some thoughts on this as well. Others (e.g. Dominick) seemed to take the opposite view on the earlier RFC discussion, i.e. that we should only check the new permission if the capability is enabled. I specifically raised that as a question there. I'm willing to change it to fallback to checking for a bounded type, but that will mean two audit messages (I don't think we can just hide one of them) when neither is allowed. That said, it is unlikely to cause much confusion in practice because users typically only look for and pay attention to AVC messages, and anyone using audit2allow will just end up allowing the permission, not the bounds. As Jason noted, if we fallback to checking for a bounded type, then we don't strictly need a policy capability for it. It seems as though Dominick is okay with the fallback, what do the rest of the policy folks think about that approach? I am okay with the faillback I'm of the opinion that changes which don't require a new policy capability are slightly more favorable, but since one of the goals with this change is to make policy development easier, I want to make sure we are actually doing that. It would appear we are, but a few explicit nods from the policy folks would be nice to see. With my coder hat on, I can see the value of having the existing behavior be available for anyone who currently uses it, so it makes sense. I agree, its only that I believe that no one is using it because it is impractical (except for mod_selinux users, and people that currently use type_bounds to deal with nosuid),, mainly because the nnp flag is inherited. The only scenario currently where, I believe, type_bounds might be prefered is containers since container process types do not change and the inheritance aspect is not much of a problem. With my policy hat on, I don't have an opinion on a fallback. What I do know is I don't like typebounds, avoid it as much as possible, and strongly prefer it not be forced on me. There are no typebounds in refpolicy. In fact, I think NNP should not affecting SELinux at all as NNP is discretionary and SELinux is mandatory. NNP makes sense where you start out with lots of privileges and have to shed them, (i.e. the Linux DAC/capabilities perspective) whereas you have no privileges in SELinux except what is explicitly allowed. Once this permission is implemented I'll likely add the permission across most if not all transitions out of systemd. Yes but do not expect that to ,always, be enough due to the inheritance aspect. A process may have inherited the NNP flag, not because its started by systemd but because its started by a process that inherited the NNP flag because it was started by systemd. That just makes me want to apply the permission to all transitions for all domains. Not that I'm planning to do it in refpolicy. I'm definitely inclined to be very liberal in applying the permission in refpolicy. For my personal systems, I'd probably do an: allow domain domain:process nnp_nosuid_transition; so I don't ever have to think about it again. -- Chris PeBenito
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On 07/13/2017 04:11 PM, Dominick Grift wrote: On Thu, Jul 13, 2017 at 03:59:29PM -0400, Stephen Smalley wrote: On Thu, 2017-07-13 at 21:43 +0200, Dominick Grift wrote: On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote: On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote: On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote: On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote: On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote: On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote: On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote: On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote: On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley wrote: On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote: On 07/12/2017 05:38 PM, Paul Moore wrote: On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley wrote: On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote: On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley wrote: While I think splitting the NNP/nosuid transition restrictions might be a good idea under the new policy capability, I'm not sure it is worth the cost of a "process2" object class. With that in mind, let's do two things with this patch: * Mention the nosuid restrictions in the patch description. It doesn't need much text, but something would be good so we have documentation in the git log. * Let's pick a new permission name that is not specific to NNP or nosuid. IMHO, nnpnosuid_transition is ... less than good. Unfortunately, I'm not sure I'm much better at picking names; how about "protected_transition"? "restricted_transition "? "enable_transition"? "override_transition"? I vote for nnp_transition anyway. "No New Privileges" encompasses nosuid in my mind. If the two perms had been separated I would have been inclined to allow both every time one of them was needed, to make sure no one was surprised by the behavior difference. I agree; I'll keep it as nnp_transition and just document it in the patch description. Sorry to be a stubborn about this, but nnp_transition makes little sense for the nosuid restriction. Like it or not, NNP has a concrete meaning which is distinct from nosuid mounts. We don't have to pick any of the permission names I tossed out, none of those were very good, but I would like to see something that takes both NNP and nosuid into account, or preferably something that doesn't use either name explicitly but still conveys the meaning. NNP is essentially a superset of nosuid; it applies to all execve() calls by the process and its descendants rather than only to execve() calls on specially marked filesystems. So I viewed it as the more general term. If that's not viable, I can't think of anything clearer or better than nnp_nosuid_transition. That clearly links it to what it means (allow a SELinux domain transition under NNP or nosuid). It is somewhat ugly and verbose but it is clear in what it means, which I think is more important. All of your suggestions IMHO were less clear since they had no clear linkage to either NNP or nosuid, and I couldn't tell from reading the permission name what it meant. The SELinux domain transition isn't protected, it isn't restricted, it isn't clear what enable_transition means versus the regular transition or dyntransition permissions, and we aren't overriding a transition but rather allowing one under NNP/nosuid. The only other alternative I see is to introduce a process2 class and use separate nnp_transition and nosuid_transition permissions (but in practice I expect them to be both allowed or denied together). Note that this will require two avtab and AVC entries for every domain pair (if we allow whichever one ends up going in the process2 class), so that has an impact on policy and AVC size. Don't really see that as worthwhile. Other approach would be to make the nosuid transition checks file- based instead so that it would go in the file class (while the nnp one would remain in the process class), but I don't think that's really what we want either. Difference between "Can domain D1 transition under nosuid to D2?" and "Can domain D1 transition under nosuid when executing file with type T1?". Just to be clear, we would also be separately checking regular transition permission between the old and new contexts on these transitions, so you would need both: allow D1 D2:process transition; allow D1 T1:file nosuid_transition; if we took the latter approach. So we wouldn't lose entirely on a domain-to-domain check, but it would no longer be domain-to-domain for the nosuid part. Whereas with original approach, we end up requiring: allow D1 D2:process transition; allow D1 D2:process nnp_nosuid_transition; # or whatever permission name is used I don't know if i understand all the ins-and-outs of the matter but i think i do like the idea of differentiating between n
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On 07/12/2017 05:38 PM, Paul Moore wrote: On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote: On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote: On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote: While I think splitting the NNP/nosuid transition restrictions might be a good idea under the new policy capability, I'm not sure it is worth the cost of a "process2" object class. With that in mind, let's do two things with this patch: * Mention the nosuid restrictions in the patch description. It doesn't need much text, but something would be good so we have documentation in the git log. * Let's pick a new permission name that is not specific to NNP or nosuid. IMHO, nnpnosuid_transition is ... less than good. Unfortunately, I'm not sure I'm much better at picking names; how about "protected_transition"? "restricted_transition"? "enable_transition"? "override_transition"? I vote for nnp_transition anyway. "No New Privileges" encompasses nosuid in my mind. If the two perms had been separated I would have been inclined to allow both every time one of them was needed, to make sure no one was surprised by the behavior difference. -- Chris PeBenito
Re: Policy capabilities: when to use and complications with using
left the capability names as strings in the kernel policy (new binary format version), then we would no longer need to update libsepol for each new policy capability. The kernel would then turn the list into the bitmap internally. The downside is that we would lose validation of the capability names when policy is built, and it isn't clear how the kernel should handle unknown names (presently the kernel will simply ignore any unknown capabilities in the bitmap). Failing at policy load time would mean we can't enable the capability in policy without making it depend on a particular kernel version. I wonder if in the case of a new permission being added whether the kernel could revert to the previous behavior if the new permission is not in the policy. The new permission would be an implicit policy capability. I'm not a fan of implicit behaviors. It leads to unexplained behavior for the uninitiated. Even if we just included strings in the kernel policy it would still be nice to have something in libsepol, so that typos would be caught. The lack of any direct relationship between policy capabilities and the classes/permissions they affect also can be misleading. For example, someone booting a recent kernel might see warnings about undefined classes introduced by the extended_socket_class feature and add those class definitions to their policy, which will silence the kernel warning and make them think that they are actually using those classes now. But they won't actually get used until they declare the capability too in their policy, and the kernel doesn't warn about that (nor does it necessarily make sense to do so, since that may be a conscious choice by the policy author). The kernel could however log each policy capability and its state as part of its normal logging and leave it up to the reader to decide whether those values are correct or not. We also had talked originally about checkpolicy and friends possibly warning on inconsistencies, while leaving it up to the policy author. If the permissions acted as an implicit policy capability, that would take care of this problem. The kernel could warn that since the new permission is missing then these checks would be different. So: 1) Should we investigate lighter weight support for policy capabilities, and if so, how? 2) Should the kernel log information about enabled/disabled policy capabilities in much the same manner as it does for undefined classes/permissions? Yes, I think it should. 3) Should the policy compiler toolchain warn the user if a policy capability is not declared and classes/permissions are used in rules that will only be used if that policy capability is declared? And similarly if a policy capability is declared but the corresponding classes/permissions are not used in any rules? I think this is yes too. For policy maintainers, it keeps reminding us there is something important to address (I admit I forgot about extended_socket_class). For end users, it notifies them that their policy may not have the intended effect. 4) Do we need/want a policy capability for map permission and other cases where we are only adding a new permission check? Or should we continue to reserve them for cases not addressed via handle_unknown? I haven't come to a conclusion for a general rule, but for map, I'd expect that there wouldn't be a big impact by adding it in. The (my guess) 99% would be handled by the one refpolicy interface that allows all the general shared lib access. I know you also want this: 5) Should CIL support adding a permission to a new class, so we don't need to grab a source rpm and rebuild the whole policy from source just to test a new permission? Jim [1] https://github.com/SELinuxProject/selinux-kernel/issues/13 -- Chris PeBenito
ANN: Reference Policy Release
A new release, 2.20170204, of the SELinux Reference Policy is now available on the GitHub site: https://github.com/TresysTechnology/refpolicy/wiki/DownloadRelease The full changelog is too long to include in this email, so here's the diffstat instead: Core: 155 files changed, 1930 insertions(+), 813 deletions(-) Contrib: 505 files changed, 1840 insertions(+), 903 deletions(-) -- 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.
ANN: SETools 4.1.0
I'm pleased to announce the SETools 4.1.0 release, available here: https://github.com/TresysTechnology/setools/releases/tag/4.1.0 This release primarily focused on adding features to apol, but has several library enhancements. There is also one important bugfix in sediff. There were no changes since 4.1.0-rc. Note: This will not compile on the master branch of libsepol (what will be libsepol 2.7). A future release of SETools will have this support (after libsepol 2.7 is released). Changes since 4.0.1: Library: * Implemented support for alternate install prefixes. * Implemented support for building setools with a locally-built libsepol. * Fixed an sediff bug with unioning rules after expansion. * Improved sediff memory usage. * Patch from Nicolas Iooss to make more stable output in TE rule permission lists. * Replaced string representations (e.g. rule types) with enumerations. Requires the enum34 (not enum) Python package if using Python < 3.4. Apol: * Implemented context menu option for exporting the information flow and domain transition analysis tree browser views. * Implemented CSV export of table results. * Implemented (clipboard) copy from table results. * Added missing "clear" button in object class query. * Implemented save/load settings for tabs. * Implemented save/load workspace (save all tabs settings). * Fixed include/exclude type dialog to keep its place when adding or removing types from an analysis. * Implemented filter on include/exclude type dialog to filter the lists by attribute. Warning: If you use the 2.5 SELinux userspace toolchain and use this to replace SETools 3.x on your system, it will break the couple of tools from sepolgen/policycoreutils that depend on SETools (e.g. sepolicy) since libqpol/libapol C libraries and their corresponding Python wrappers are no longer provided. The >=2.6 SELinux userspace toolchain has updated its support to setools4, and does not have this problem. -- 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.
ANN: SETools 4.1.0-rc
I'm pleased to announce the SETools 4.1.0-rc release, available here: https://github.com/TresysTechnology/setools/releases/tag/4.1.0-rc This release primarily focused on adding features to apol, but has several library enhancements. There is also one important bugfix in sediff. Changes since 4.0.1: Library: * Implemented support for alternate install prefixes. * Implemented support for building setools with a locally-built libsepol. * Fixed an sediff bug with unioning rules after expansion. * Improved sediff memory usage. * Patch from Nicolas Iooss to make more stable output in TE rule permission lists. * Replaced string representations (e.g. rule types) with enumerations. Requires the enum34 (not enum) Python package if using Python < 3.4. Apol: * Implemented context menu option for exporting the information flow and domain transition analysis tree browser views. * Implemented CSV export of table results. * Implemented (clipboard) copy from table results. * Added missing "clear" button in object class query. * Implemented save/load settings for tabs. * Implemented save/load workspace (save all tabs settings). * Fixed include/exclude type dialog to keep its place when adding or removing types from an analysis. * Implemented filter on include/exclude type dialog to filter the lists by attribute. Warning: If you use the 2.5 SELinux userspace toolchain and use this to replace SETools 3.x on your system, it will break the couple of tools from sepolgen/policycoreutils that depend on SETools (e.g. sepolicy) since libqpol/libapol C libraries and their corresponding Python wrappers are no longer provided. The >=2.6 SELinux userspace toolchain has updated its support to setools4, and does not have this problem. -- 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: [Patch v2 2/2] policycoreutils: Make sepolicy work with python3
On 11/08/16 10:29, Stephen Smalley wrote: On 11/08/2016 10:21 AM, Stephen Smalley wrote: On 11/07/2016 04:51 AM, Laurent Bigonville wrote: From: Laurent Bigonville <bi...@bigon.be> Add python3 support for sepolicy Signed-off-by: Laurent Bigonville <bi...@bigon.be> --- policycoreutils/sepolicy/selinux_client.py | 6 ++-- policycoreutils/sepolicy/sepolicy.py | 38 policycoreutils/sepolicy/sepolicy/__init__.py| 16 ++ policycoreutils/sepolicy/sepolicy/communicate.py | 4 +-- policycoreutils/sepolicy/sepolicy/generate.py| 30 +-- policycoreutils/sepolicy/sepolicy/interface.py | 14 ++--- policycoreutils/sepolicy/sepolicy/manpage.py | 7 +++-- 7 files changed, 65 insertions(+), 50 deletions(-) make test doesn't pass in policycoreutils/sepolicy, although I'm not sure that's new to this patch. I think the manpage ones were already failing; I don't recall the network one hanging before though. But maybe that is because I wasn't testing with setools3 fully removed before? Oh, I guess it is just very slow with setools4. It did finally complete sepolicy network -d and has moved on (next slow/hanging one is transition -t). Yes, sadly setools4 is slower. I haven't spent much time on trying to improve the performance yet (preliminary profiling seems to indicate that swig is the problem). However, looking through the sepolicy code, I found that it could use the setools code more efficiently (I realize the first matter of business was just to get it over to setools4). The biggest win will be to minimize how many times the code iterates over all TE rules. For example, in the search function, it runs the TERuleQuery twice, when it could be done in one query. Also, for the transition command, it seems to manually implement a domain transition analysis. When I compared the sepolicy transition run time to sedta, sedta was a minute faster for the same analysis. -- 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.
ANN: Reference Policy Release
A new release of the SELinux Reference Policy is now available on the GitHub site, https://github.com/TresysTechnology/refpolicy. The full changelog is too long to include in this email, so here's the diffstat instead: Core: 82 files changed, 1411 insertions(+), 225 deletions(-) Contrib: 125 files changed, 1275 insertions(+), 133 deletions(-) -- 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
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: [PATCH 1/1] genhomedircon: support policies using RBACSEP
On 09/26/16 10:20, Stephen Smalley wrote: On 09/24/2016 04:26 AM, Dominick Grift wrote: On 09/23/2016 09:36 PM, Stephen Smalley wrote: On 09/23/2016 10:28 AM, Gary Tierney wrote: Introduces support for generating homedir/user contexts for policies that implement RBACSEP. The support works by taking the prefix of a logins seuser and replacing the role field in their context specifications with the prefix. A new option "genhomedircon-rbacsep" was added to /etc/selinux/semanage.conf to allow toggling this behavior. The user prefix was previously used as a prefix for types, e.g. you could have: HOME_DIR/\.gnupg(/.+)? system_u:object_r:ROLE_gpg_secret_t and get it replaced with: /home/[^/]+/\.gnupg(/.+)? system_u:object_r:user_gpg_secret_t /root/\.gnupg(/.+)? system_u:object_r:sysadm_gpg_secret_t So I guess you could use it for the role field too, but for consistency you would want it to be: HOME_DIR/\.gnupg(/.+)? system_u:ROLE_r:ROLE_gpg_secret_t and the prefix would still just be "user". No one is actually using that privsep functionality anymore. Reference policy removed support for it. Can we not instead just re-use that code for rbacsep? The alternative would be to add code similar to the privsep code but then for rbacsep. Then we will have the issue that we can't reasonably rely on the userprefix and prefix statements for rbacsep, because they might be used for privsep (in theory at least) I other words if we were to implement rbacsep code similar to the privsep code, then we would need a new policy statement similar to userprefix and prefix. It seems much easier to me to just re-use the privsep code. rbacsep is the successor to privsep after all. First, I'm not sure what you mean by privsep; usually that term refers to privilege separation as in openssh. There are at least three ways of implementing "role" separation for objects in SELinux: (1) via TE and the use of derived types on objects e.g. ROLE_home_t, ROLE_devpts_t, etc, (2) via RBAC and the use of roles on objects (originally problematic because it required a set of changes to the kernel to support roles on objects, but that's all history now), (3) via UBAC and the use of SELinux user identities on objects to represent roles. refpolicy started with (1), experimented with (2) and seems to have settled on (3), likely because (2) wasn't fully supported in the kernel or userspace for a long time. I guess libsemanage / genhomedircon already support (3) adequately. CIL apparently doesn't support (1), so that's broken regardless. So I guess reusing the prefix for RBACSEP won't break any existing users. That said, it is clearly confusing to use something identified in the policy language and documentation as a "prefix" for the purpose of a "default role". So maybe we should look to rename it in the language and code, with backward compatibility. That can be done as a separate set of changes. That might also help us with a different problem - obsoleting security_compute_user() aka /sys/fs/selinux/user and taking the get_default_context() logic to userspace. Has anyone compared UBAC vs RBAC now that the kernel and policy support roles on objects? Is there a strong reason for refpolicy to stay with (3) other than compatibility with older distributions and this genhomedircon issue? I'm open to reimplementing RBAC-based separations in refpolicy. I started working on it but couldn't decide how best to structure the role-type associations and if role_transitions or default_role was the cleaner way to go to get roles on objects (e.g. consider how to handle non-separated types). These days I'm more interested in getting a refpolicy high-level language implemented, now that CIL is generally available. The problem is compilers isn't my thing, so I haven't really gotten anywhere yet. -- 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: [PATCH] semanage: swap tcp and udp protocol numbers
On 08/10/16 04:39, Miroslav Vadkerti wrote:
The tcp/udp protocol numbers were accidentaly swapped in
the original patch 'semanage: add auditing of changes in records'.
Signed-off-by: Miroslav Vadkerti <mvadk...@redhat.com>
---
policycoreutils/semanage/seobject.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/policycoreutils/semanage/seobject.py
b/policycoreutils/semanage/seobject.py
index 317b421..786ed0e 100644
--- a/policycoreutils/semanage/seobject.py
+++ b/policycoreutils/semanage/seobject.py
@@ -88,8 +88,8 @@ file_type_str_to_option = {"all files": "a",
"symbolic link": "l",
"named pipe": "p"}
-proto_to_audit = {"tcp": 17,
- "udp": 6,
+proto_to_audit = {"tcp": 6,
+ "udp": 17,
"ipv4": 4,
"ipv6": 41}
I realize this has already been merged, but why not use existing
constants such as socket.IPPROTO_TCP and socket.AF_INET rather than hard
coding the protocol numbers?
--
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: Should port 3269 be ldap_port_t?
On 08/03/16 08:48, Colin Powers wrote: Hi all, First of all apologies if something has changed in this area recently, I have checked on a RHEL 7 machine and noticed the omission. LDAP is associated with the following ports: - 389 for plain LDAP - 686 for LDAPS - 3268 for Global Catalog - 3269 for Global Catalog over LDAPS All of these ports are ldap_port_t except 3269 which is not given any special type. Because of this, my Apache set-up was unable to perform LDAP authorisation while in enforcing. Obviously I can fix the issue with semanage, but should 3269 be ldap_port_t out of the box? This type of question is more appropriate for the refpolicy list. However, I've added the port labeling in refpolicy. -- 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: rpm running with MLS range?
On 07/22/16 09:41, Miroslav Grepl wrote:
Hi folks,
we define a MLS range for some directories in the policy and because we
have a SELinux support in rpm, we can end up with AVC msgs like
type=AVC msg=audit(1461664028.583:784): avc: denied { relabelto } for
pid=14322 comm="yum" name="libvirt" dev="dm-0" ino=670147
scontext=root:system_r:rpm_t:s0
tcontext=system_u:object_r:virt_cache_t:s0-s15:c0.c1023 tclass=dir
Does it make sense to have rpm_t running with a range or should we think
about a new MLS attribute for "file ( relableto )"?
Normally package managers aren't processing sensitive (in the MLS sense)
data. Creating objects higher than system low is an exceptional case,
so I'd go with a new MLS exception (attribute).
--
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.
