[idea] multiple contexts.

[idea] multiple contexts.

[Luke Kenneth Casson Leighton]

i'd like to propose an extension to the SE/Linux system: it's quite
straightforward and it could possibly be implemented in the macro
system - maybe, maybe not.

the ultimate aim is to help simplify the production of policies.

the idea is simple: to be able to have more than one context, and
to be able to make auditing decisions based on more than one context.

extensions
----------

domain_auto_trans(user_t, kdeinit_exec_t, +kde_user_t);

note the plus sign: this means "whenever a user executes the executable
program kdeinit, then instead of transitioning TO the kde_user_t
context, they get an EXTRA context kde_user_t".

domain_auto_trans(kde_user_t&user_t, skype_exec_t, skype_t);

note the use of _two_ contexts: this means "whenever a user who
is in BOTH the kde_user AND the user context, executes the
skype VoIP application, they transition to the skype_t context".

implications
------------

in other words, this has the effect of limiting users to only
be able to run certain KDE applications.

in a really simple and straightforward manner.

the alternative is that i will have to write a set of policy files
on a per-KDE-application basis.

and i'll have to deal with them walking through kdeinit, which is
a pain.

if there was a means to "attach" a second context which was unaffected
and carried over "through" other execve system calls, it'd be
possible to "pick it up" on the other side of the execve'd use of
"kdeinit".

exim4 would also, i believe, be a doddle, and i do not believe it
would need the hacks to exim4 to make it call different binary
names for different functions.

second contexts could be "attached" to the exim4_exec_t - a
sendmail_something_t context which would "activate" allow rules
based on allow exim4_exec_t&sendmail_something_t, .... instead of
just allow exim4_exec_t .....

implementations
---------------

i thought it might be possible to use pre-processing macro
expansion to do the same job as hacking the selinux source code.

fortunately, my subconscious disabused me of that notion over the
last two days, and threw up the kdeinit and the exim4 examples
as cases which could be solved by multiple-contexts.

... alternatively, yes, actually, thinking about it: the idea
recommended by russell which is to exec to an alternate binary
that then execs to the same binary *IS* a multiple-context
"shim".

in case you missed it, exim4 is a single binary which frequently
execve's to itself with new arguments: e.g. to open up a transport
it does execve("exim4", "-M", ...) and stuff.

russell's idea was to replace exim4 in the above example with
exim4-M, and then to write a SEPARATE policy file for a binary
named exim4-M.

that exim4-M is a one-liner that calls execve to exim4 with its
argv[] arguments is, to exim4, irrelevant: the effect of going
via a different binary IS that exim4 "picks up" an extra context.


... now, i sure as heck don't wanna go through that with kdeinit.

to solve the same issue for kdeinit, i would have to write and
compile STACKS of these little binaries, and would have to do
something like find and double-check the locations where kdeinit
is called (including third party applications), prefix the
name of the program being called with kdeinit, execve to that
binary (/usr/bin/kdeinit-konqueror, /usr/bin/kdeinit-kdesktop,
/usr/bin/kdeinit-ksmserver), which would then execve all its
char *argv[] arguments _back_ to kdeinit, and write an SELinux
policy for every single new little program kdeinit-konqueror
kdeinit-khotkeys kdeinit-kio_file THE WORKS.

there are OVER A HUNDRED programs beginning with k, most of which
are kde ones, and that's not even with the full kde suite installed
(i use fvwm) and precious few of the optional packages.

without this "multiple contexts" idea in place, it's a stacking big
task with no "default" to fall back on - that i can think of.


i feel certain that there are other areas where this "multiple contexts"
idea will have other benefits, to simplify auditing and enhance
selinux.

i know it's a bit like unix groups, only you can't do file permission
checks in POSIX based on being in _more_ than one group, so it's
actually a lot more powerful a concept.

i also feel, intuitively, that it might help with the issues involving
users.  i cannot _begin_ to comprehend what that is about, but i
see a lot of messages six weeks ago indicating that there appears
to be a history of problems as the number of users increases on
an selinux system [at least, that's what it looked like] ...

but i see no solutions.

would "multiple contexts" help at all?

l.



-- 
-- 
Information I post is with honesty, integrity, and the expectation that
you will take full responsibility if acting on the information contained,
and that, should you find it to be flawed or even mildly useful, you
will act with both honesty and integrity in return - and tell me.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
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: [idea] multiple contexts.

[Russell Coker]

On Sun, 25 Jul 2004 09:11, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> note the plus sign: this means "whenever a user executes the executable
> program kdeinit, then instead of transitioning TO the kde_user_t
> context, they get an EXTRA context kde_user_t".

Nothing that you could do with kdeinit will give a good result.

kdeinit is a hack to avoid the time taken for loading shared objects (less 
than 1 second of CPU time on a P3-650).  Like most hacks it causes problems 
for other things, in this case for security systems of which SE Linux is only 
one example.

If you get a 1GHz machine (one of those cheap new VIA systems or a cheap 
second-hand system) then you probably won't mind the small extra overhead of 
loading shared objects.  Also removing the kdeinit hack will probably avoid 
most of the problems of KDE acting weird when you upgrade your system while 
still logged in.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: [idea] multiple contexts.

[Stephen Smalley]

On Sat, 2004-07-24 at 19:11, Luke Kenneth Casson Leighton wrote:
> i'd like to propose an extension to the SE/Linux system: it's quite
> straightforward and it could possibly be implemented in the macro
> system - maybe, maybe not.
> 
> the ultimate aim is to help simplify the production of policies.
> 
> the idea is simple: to be able to have more than one context, and
> to be able to make auditing decisions based on more than one context.

Not a good idea, and not necessary.  You can encode the entire call
chain in a single security context using the domain transitions, and can
then unwind as desired.  Fortunately, it sounds like the kdeinit problem
is easily solved anyway.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: [idea] multiple contexts.

[Luke Kenneth Casson Leighton]

On Mon, Jul 26, 2004 at 12:12:03PM -0400, Stephen Smalley wrote:
> On Sat, 2004-07-24 at 19:11, Luke Kenneth Casson Leighton wrote:
> > i'd like to propose an extension to the SE/Linux system: it's quite
> > straightforward and it could possibly be implemented in the macro
> > system - maybe, maybe not.
> > 
> > the ultimate aim is to help simplify the production of policies.
> > 
> > the idea is simple: to be able to have more than one context, and
> > to be able to make auditing decisions based on more than one context.
> 
> Not a good idea, and not necessary.  You can encode the entire call
> chain in a single security context using the domain transitions, 

 well, not entirely - not dynamically, anyway: at least i do not
 believe so.

 i thought originally that it would be possible to do what i envisaged
 with m4, by extending the policy language.


> and can
> then unwind as desired.  Fortunately, it sounds like the kdeinit problem
> is easily solved anyway.

 i also seek to limit the programs that a KDE user may run.

 if there is a simple way to do that which does not involve writing
 policy files for each and every single KDE program i intend to restrict
 users to use, i would be interested to hear it.

 l.


--
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: [idea] multiple contexts.

[Stephen Smalley]

On Tue, 2004-07-27 at 12:06, Luke Kenneth Casson Leighton wrote:
>  well, not entirely - not dynamically, anyway: at least i do not
>  believe so.
> 
>  i thought originally that it would be possible to do what i envisaged
>  with m4, by extending the policy language.

There are already plenty of cases where derived domains are defined via
macros, so that the new domain expresses information about both the
caller and the newly executed program.  Even in your example, kde_user_t
is an example of a derived domain that can implicitly indicate that the
caller was user_t, without needing multiple contexts at all.

Introducing multiple contexts per process would have a significant
impact on the security model and analysis of a policy.

>  i also seek to limit the programs that a KDE user may run.
> 
>  if there is a simple way to do that which does not involve writing
>  policy files for each and every single KDE program i intend to restrict
>  users to use, i would be interested to hear it.

I'm not sure why this is a problem; you can already define what program
types can be executed by a given domain.  Possibly I just don't
understand, as I haven't used KDE myself.

With regard to the exim4 example, it would seem to make sense to have
exim4 use the policy API to compute contexts based on a configuration
and setexeccon() to these contexts explicitly to avoid having to
maintain all of the different wrapper programs.  But it isn't that it is
picking up an extra context; it is changing to a new context, one that
has its own particular set of permissions in the policy.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: [idea] multiple contexts.

[Luke Kenneth Casson Leighton]

On Tue, Jul 27, 2004 at 01:33:15PM -0400, Stephen Smalley wrote:
> On Tue, 2004-07-27 at 12:06, Luke Kenneth Casson Leighton wrote:
> >  well, not entirely - not dynamically, anyway: at least i do not
> >  believe so.
> > 
> >  i thought originally that it would be possible to do what i envisaged
> >  with m4, by extending the policy language.
> 
> There are already plenty of cases where derived domains are defined via
> macros, so that the new domain expresses information about both the
> caller and the newly executed program.  Even in your example, kde_user_t
> is an example of a derived domain that can implicitly indicate that the
> caller was user_t, without needing multiple contexts at all.
 
 ah ha!

 okay.

 perhaps this will make it clearer.

 is it possible to write, in macro form, a policy which will allow
 only a subset of KDE programs to be run...

 ... _without_ affecting, changing or impacting the existing policies
 under which user_t runs kde programs, and preferably _without_ having
 to copy a stack-load of things from user_t to [the proposed]
 kde_user_t.

 you see, at present, what i would do is:

 - define a user type kde_user_t

 - make startkde transition to kde_user_t

 - define one policy per kde program.
 
 - start running programs, running audit2allow whenever something
   broke, and add the permissions to the relevant program's policy.


 now, whilst this is possibly the best (paranoid) way to do it
 (you get to vet the functionality of every KDE program under
 the sun), this ain't too _intelligent_ a way to do it :)

 what i would _prefer_ to do is to "jump" into user_t context ....
 but only for certain programs.


 okay.  i know a good way to describe it.

 under POSIX, i would just create a group kdeprogs, make the users
 a member of that group, allow execute permission to certain kde
 programs for group kdeprogs, chgrp the programs to that group, and
 be done with it, making sure to take extra care of root-setuid
 programs.

 hey, i might end up doing that after all.

 but i would _prefer_ it if i could somehow do the same thing using
 SE/Linux.

 and that "multiple contexts" idea was one way i thought that might
 be achievable.

 l.


--
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: [idea] multiple contexts.

[Erich Schubert]

Hi,

On the multiple contexts thing:
The power set of a finite set is still finite. I.e. you don't need to
have multiple context if you are willing to manage enough contexts.
It's just a matter of writing appropriate macros...
You could name your contexts like sysadm_kde_mail_foobar_something
for the context having the access rights of sysadm, kde, mail etc.

The thing is: you don't want to allow any combination.
For example you don't want a context which can use both KDE and write to
system applications. Keeping such things exclusive is a good thing.
When you allow multiple context you would need to write many rules like
"when switching to context xyz, drop context foo" - that is not better.

Why not define roles "kde_with_shell_r" and "kde_without_shell_r" and
write appropriate access rules? (or: "kde_full_r" and "kde_limited_r")

This makes it a lot easier to verify.

Also you avoid conflicts, rules are explicit. kde_full_r can exec xterm,
kde_limited_r cannot. You can't have the case that a user has both
contexts - should he be allowed access or not?

Greetings,
Erich Schubert
-- 
    erich@(mucl.de|debian.org)      --      GPG Key ID: 4B3A135C    (o_
     Go away or i'll replace you with a very small shell script.    //\
    Der Anfang aller Erkenntnis ist das Staunen. --- Aristoteles    V_/_

--
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: [idea] multiple contexts.

[Luke Kenneth Casson Leighton]

On Thu, Jul 29, 2004 at 01:16:30AM +0200, Erich Schubert wrote:
> Hi,
> 
> On the multiple contexts thing:
> The power set of a finite set is still finite. I.e. you don't need to
> have multiple context if you are willing to manage enough contexts.
> It's just a matter of writing appropriate macros...

> Why not define roles "kde_with_shell_r" and "kde_without_shell_r" and
> write appropriate access rules? (or: "kde_full_r" and "kde_limited_r")

 i've just noticed the sudo_domain() macros, and their friends
 irc_domain() and sendmail_ etc.

 whilst i don't yet sufficiently get the principle of these
 to make use of it properly (i tried earlier today) i at least
 understand what they are intended to do: to "combine" what
 i perceive to be two contexts (user_t and kde_t).

 l.


--
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: [idea] multiple contexts.

[Valdis.Kletnieks]

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

On Tue, 27 Jul 2004 17:06:06 BST, Luke Kenneth Casson Leighton said:

>  i also seek to limit the programs that a KDE user may run.
> 
>  if there is a simple way to do that which does not involve writing
>  policy files for each and every single KDE program i intend to restrict
>  users to use, i would be interested to hear it.

Are there KDE programs that don't require anything but user permissions, but
that you want to restrict anyhow?

Or are all the programs to be limited already require more permission?

Or are you trying to secure a kiosk?

The answers will probably depend on what problem you're trying to solve?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [idea] multiple contexts.

[Luke Kenneth Casson Leighton]

On Tue, Jul 27, 2004 at 03:40:37PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 27 Jul 2004 17:06:06 BST, Luke Kenneth Casson Leighton said:
> 
> >  i also seek to limit the programs that a KDE user may run.
> > 
> >  if there is a simple way to do that which does not involve writing
> >  policy files for each and every single KDE program i intend to restrict
> >  users to use, i would be interested to hear it.
> 
> Are there KDE programs that don't require anything but user permissions, but
> that you want to restrict anyhow?
 
 yes, sort-of: more that i only wish to limit what programs a user
 can run (and what programs _those_ programs can run).

 in particular, i want to stop people from being able to use the
 "Run" capability of Konqueror, etc.  STOP, not have the popup coming
 up with "are you sure you want to run this program?".


 setting up a kdeusers group, chgrp'ing the allowed programs
 to that group, and setting permissions to 0660 is what i really
 need...

 ... but i wondered if there was a way to do that same thing in
 SE/Linux...

 ... _without_ writing a whole stack of policies, one per program.

 a macro i could write that would let me do this:
 
 allow_user_kde_access(konqueror_exec_t)
 allow_user_kde_access(k3b_exec_t)

 with all that that implies.

 or, to simply set all the allowed kde executables into
 kde_user_exec_t type, and set this on /usr/bin/konqueror,
 /usr/bin/k3b, /usr/bin/koffice etc.

 l.


--
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: [idea] multiple contexts.

[Valdis.Kletnieks]

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

On Tue, 27 Jul 2004 22:28:36 BST, Luke Kenneth Casson Leighton said:

>  yes, sort-of: more that i only wish to limit what programs a user
>  can run (and what programs _those_ programs can run).
> 
>  in particular, i want to stop people from being able to use the
>  "Run" capability of Konqueror, etc.  STOP, not have the popup coming
>  up with "are you sure you want to run this program?".

Do these users have anything resembling shell access? If they can get an xterm
or an editor open, they can run the program *anyhow*....

Probably easier to do the kdeuser group and start chgrp'ing, than to try to fight THAT
war.

Or see how hard it would be to create a patch to Konqueror to disable the
button, and see if you can push it upstream...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [idea] multiple contexts.

[Luke Kenneth Casson Leighton]

On Tue, Jul 27, 2004 at 05:23:38PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 27 Jul 2004 22:28:36 BST, Luke Kenneth Casson Leighton said:
> 
> >  yes, sort-of: more that i only wish to limit what programs a user
> >  can run (and what programs _those_ programs can run).
> > 
> >  in particular, i want to stop people from being able to use the
> >  "Run" capability of Konqueror, etc.  STOP, not have the popup coming
> >  up with "are you sure you want to run this program?".
> 
> Do these users have anything resembling shell access? If they can get an xterm
> or an editor open, they can run the program *anyhow*....
 
 no, xterm will not be on the list of programs they can run :)

 when i say it'll be a list of programs that they can run i MEAN
 if it ain't on the list it ain't gonna run.

 i.e. it's mandatory access control, 

> Probably easier to do the kdeuser group and start chgrp'ing, than to try to fight THAT
> war.
> 
> Or see how hard it would be to create a patch to Konqueror to disable the
> button, and see if you can push it upstream...

 there are more places, there are more programs.

 other programs, such as ksmoothdock, such as Basket, such as kxdocker,
 such as KMenu being edited and people manually putting programs onto
 their menus.

 all of these things i just don't wanna know about _how_ they are run:
 if they ain't on the list, splat.

 make a user a member of kdeusers + chgrp-to-kdeusers + 0660 on all
 exes in the "allowed list" is my "fallback" position.

 i'd just rather it wasn't the only position.

 l.

--
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: [idea] multiple contexts.

[David Caplan]

Luke Kenneth Casson Leighton wrote:
>  
>  yes, sort-of: more that i only wish to limit what programs a user
>  can run (and what programs _those_ programs can run).
> 

That seems pretty straightforward using transition rules.

>  in particular, i want to stop people from being able to use the
>  "Run" capability of Konqueror, etc.  STOP, not have the popup coming
>  up with "are you sure you want to run this program?".
> 

You may not have to worry about that if you've defined, via policy, what 
the user (i.e., the domain they are in when running Konqueror, etc.) is 
allowed to run.

> 
>  setting up a kdeusers group, chgrp'ing the allowed programs
>  to that group, and setting permissions to 0660 is what i really
>  need...
> 

0660 is -rw-rw----, I think you meant 0550, -r-xr-x---, right?

>  ... but i wondered if there was a way to do that same thing in
>  SE/Linux...
> 
>  ... _without_ writing a whole stack of policies, one per program.
> 

That's your real issue.  You can accomplish the equivalent (of your 
chgrp scenario) by defining a domain for all the allowed user programs 
and causing a domain transition whenever a user (in your limited user 
domain) executes an allowed program.  Then you only have to write a 
policy that covers the needs of the set of allowed user applications. 
That gets you the equivalent (actually it's possibly a _little_ better 
because you limited the permissions to only what the group needs and you 
removed excess permissions that the user may have had when they enter 
the new domain).

What you really _need_ is a whole stack of policies so that each program 
is limited to only what it needs.  It's up to you to determine if your 
intended environment requires the effort to do that. With some analysis 
you may also find that you can define policies for subgroups of programs 
instead of having individual policies for every program.

>  a macro i could write that would let me do this:
>  
>  allow_user_kde_access(konqueror_exec_t)
>  allow_user_kde_access(k3b_exec_t)
> 
>  with all that that implies.
> 
>  or, to simply set all the allowed kde executables into
>  kde_user_exec_t type, and set this on /usr/bin/konqueror,
>  /usr/bin/k3b, /usr/bin/koffice etc.
> 

You just need to be very careful that you don't end up granting so much 
permission to a generic kde domain that you've accomplished nothing. 
I'd recommend the judicious use of neverallows to ensure that you've not 
accidentally allowed something you meant to deny.  I'd also recommend 
the use of our analysis tool, apol (www.tresys.com/selinux ).

David


-- 
__________________________________

David Caplan     410 290 1411 x105
dac@tresys.com
Tresys Technology, LLC
8840 Stanford Blvd., Suite 2100
Columbia, MD 21045



--
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: [idea] multiple contexts.

[Luke Kenneth Casson Leighton]

On Wed, Jul 28, 2004 at 08:33:21AM -0400, David Caplan wrote:
> Luke Kenneth Casson Leighton wrote:
> > 
> > yes, sort-of: more that i only wish to limit what programs a user
> > can run (and what programs _those_ programs can run).
> >
> 
> That seems pretty straightforward using transition rules.
> 
> > in particular, i want to stop people from being able to use the
> > "Run" capability of Konqueror, etc.  STOP, not have the popup coming
> > up with "are you sure you want to run this program?".
> >
> 
> You may not have to worry about that if you've defined, via policy, what 
> the user (i.e., the domain they are in when running Konqueror, etc.) is 
> allowed to run.
> 
> >
> > setting up a kdeusers group, chgrp'ing the allowed programs
> > to that group, and setting permissions to 0660 is what i really
> > need...
> >
> 
> 0660 is -rw-rw----, I think you meant 0550, -r-xr-x---, right?
 
 oh, duh, yes.

> > ... but i wondered if there was a way to do that same thing in
> > SE/Linux...
> >
> > ... _without_ writing a whole stack of policies, one per program.
> >
> 
> That's your real issue.  You can accomplish the equivalent (of your 
> chgrp scenario) by defining a domain for all the allowed user programs 
> and causing a domain transition whenever a user (in your limited user 
> domain) executes an allowed program.  Then you only have to write a 
> policy that covers the needs of the set of allowed user applications. 

 yes, and that basically duplicates the entire set of user_t ...
 but for kde_user_t.

 i _really_ don't want to have to rewrite / copy and-then-maintain
 a duplicated set of user_t macros which are identical in _all_ respects
 to user_t except %s/user_t/kde_user_t/g


 that was the whole point of recommending a multiple-context
 thing: _adding_ kde_user_t to be "carried along" by a domain
 transition from user_t to kde_user_t _plus_ user_t through the
 execution of startkde, and then adding a few policy rules to
 allow kde_user_t _plus_ user_t permission to execute a few
 choice executables (those and only those "on the list").


> That gets you the equivalent (actually it's possibly a _little_ better 
> because you limited the permissions to only what the group needs and you 
> removed excess permissions that the user may have had when they enter 
> the new domain).

 

> What you really _need_ is a whole stack of policies so that each program 
> is limited to only what it needs.  

 yes.

> It's up to you to determine if your 
> intended environment requires the effort to do that. 

 not really, not right now! :)

 anyway, it's been made clear that a multiple policy idea is not
 desirable: it's quite a seriously large change to the design of
 selinux.

 l.


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