policy under version control

policy under version control

[Andreas Schuldei]

I find it tiresom and uneffective to make changes to policy
without and easy way to feed my effords upstream. Actually i feel
selinux stands and falls with a smoothly working policy. this
needs attention and time of many, not just one.

i would therefor suggest to create a public readabel repository
against which one can update and also some scripts for mailing
back/submitting to the repository(?) the changes needed to make
the subsystems work.

some with some clue should go through this and apply those
patches. 

does it make sense to make this a inter-distribution-spanning
process, perhaps with manpower from the nsa? the nsa policy seems
to be not intended for use, right now and lacks relevance in that
regard.

--
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: policy under version control

[Tom]

On Sat, Nov 29, 2003 at 02:26:19PM +0100, Andreas Schuldei wrote:
> I find it tiresom and uneffective to make changes to policy
> without and easy way to feed my effords upstream. Actually i feel
> selinux stands and falls with a smoothly working policy. this
> needs attention and time of many, not just one.

I second that. I get frightened every time I update the policy because
I know it'll break half my local changes.

Also, the update process needs refinement. For one, I find it very
tiresome (and error-prone!) to not bundle packages.

For example, there are many policy files that we can be reasonably sure
will be part of EVERY system. I don't know many Linux systems that
wouldn't want the rules for mount and init, for example.

Why not just lump them into one bundle? Not one .te file, but one
installer question.


> i would therefor suggest to create a public readabel repository
> against which one can update and also some scripts for mailing
> back/submitting to the repository(?) the changes needed to make
> the subsystems work.

Some of the more modern cvs replacements seem suited for this. Arch and
Subversion both might work great with a proper setup.


Also, whatever happened to Collins attempt to automate the install?


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: policy under version control

[Russell Coker]

On Sun, 30 Nov 2003 02:05, Tom <tom@lemuria.org> wrote:
> On Sat, Nov 29, 2003 at 02:26:19PM +0100, Andreas Schuldei wrote:
> > I find it tiresom and uneffective to make changes to policy
> > without and easy way to feed my effords upstream. Actually i feel
> > selinux stands and falls with a smoothly working policy. this
> > needs attention and time of many, not just one.

Currently the most effective way of getting policy changes sent upstream is to 
send them to me, I bundle them with other patches and send them to Howard.

> Also, the update process needs refinement. For one, I find it very
> tiresome (and error-prone!) to not bundle packages.
>
> For example, there are many policy files that we can be reasonably sure
> will be part of EVERY system. I don't know many Linux systems that
> wouldn't want the rules for mount and init, for example.
>
> Why not just lump them into one bundle? Not one .te file, but one
> installer question.

This is a different issue to that raised by Andreas.  It will be resolved for 
Debian when Collin's code is merged (should happen soon).

-- 
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: policy under version control

[Stephen Smalley]

On Sat, 2003-11-29 at 08:26, Andreas Schuldei wrote:
> I find it tiresom and uneffective to make changes to policy
> without and easy way to feed my effords upstream. Actually i feel
> selinux stands and falls with a smoothly working policy. this
> needs attention and time of many, not just one.
> 
> i would therefor suggest to create a public readabel repository
> against which one can update and also some scripts for mailing
> back/submitting to the repository(?) the changes needed to make
> the subsystems work.
> 
> some with some clue should go through this and apply those
> patches. 
> 
> does it make sense to make this a inter-distribution-spanning
> process, perhaps with manpower from the nsa? the nsa policy seems
> to be not intended for use, right now and lacks relevance in that
> regard.

There is already a sourceforge CVS tree, and patches can be posted to
the selinux list.

-- 
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: policy under version control

[Tom]

On Mon, Dec 01, 2003 at 10:13:35AM -0500, Stephen Smalley wrote:
> There is already a sourceforge CVS tree, and patches can be posted to
> the selinux list.

The problem I see with read-only CVS and a post-to-mailinglist approach 
is that it's non-trivial to maintain various sets of the same policy.

It seems that in the long run we won't be able to do with a single
default policy. We'll need a couple, or a modular approach. Something
very much like Debian's tasksel or other tools for other distributions
where you have 5-10 fields you can check what your machine is going to
be, and the relevant policy is then assembled automatically.


One of the things that I heard arch can do very well is allow people to
make local branches of a repository while still linking to it so that
their local changes automatically stay in sync with the upstream
repository.

That's just one idea. The more I talk and work with SE, and I work
mostly from a user perspective in that I very rarely dabble in the SE
code itself, the more I belief that the policy is the major point
deciding over broad acceptance or not.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: policy under version control

[Dale Amon]

On Mon, Dec 01, 2003 at 08:28:14PM +0100, Tom wrote:
> It seems that in the long run we won't be able to do with a single
> default policy. We'll need a couple, or a modular approach. Something
> very much like Debian's tasksel or other tools for other distributions
> where you have 5-10 fields you can check what your machine is going to
> be, and the relevant policy is then assembled automatically.

I keep my own patch diff file between mine and Russell's default
package.

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

--
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: policy under version control

[Russell Coker]

On Tue, 2 Dec 2003 06:28, Tom <tom@lemuria.org> wrote:
> It seems that in the long run we won't be able to do with a single
> default policy. We'll need a couple, or a modular approach. Something
> very much like Debian's tasksel or other tools for other distributions
> where you have 5-10 fields you can check what your machine is going to
> be, and the relevant policy is then assembled automatically.

I also see a need for multiple policy distributions, but I don't think that 
they will be close enough to each other to enable them to productively be in 
the same tree.

Some policy files such as core_macros.te can be in all policies, but most of 
the .te files won't.

I think that policies will either be close enough that macros can be used to 
merge them, or different enough that they can't be kept to gether in any way.

-- 
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: policy under version control

[Tom]

On Tue, Dec 02, 2003 at 02:30:51PM +1100, Russell Coker wrote:
> I also see a need for multiple policy distributions, but I don't think that 
> they will be close enough to each other to enable them to productively be in 
> the same tree.
> 
> Some policy files such as core_macros.te can be in all policies, but most of 
> the .te files won't.
> 
> I think that policies will either be close enough that macros can be used to 
> merge them, or different enough that they can't be kept to gether in any way.

That's exactly where a more modern replacement of 20-year-old CVS would
help. From what I read about arch, it would be well possible to define,
say:

This is Tom's Whatever Policy Repository
all macros and these and these file_contexts and domain/program files
are identical to the upstream policy (*)
these 2 files are different (**)
these 4 files replace their counterparts upstream
these 12 files are new


(*) this definition is very much like a network-aware symlink
(**) very much like a diff, with a built-in pointer to the URL of the
original


I think this'll be very much easier than a dozen people either
maintaining a dozen policies, or keeping a dozen diff sets up to date.

Also, it solves the patch nightmare for users. You go to one place and
issue a checkout command, instead of finding the original, the 5
patches you need, and then fiddling around in how to apply them in what
order to get it all working.


Note: I haven't worked with arch yet except for some testing. I'm just
trying to point out that we could make our lives easier. I volunteer
for setting up an arch repository for a testrun, if there's enough
people interested.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: policy under version control

[Brian May]

On Tue, Dec 02, 2003 at 08:08:34AM +0100, Tom wrote:
> That's exactly where a more modern replacement of 20-year-old CVS would
> help. From what I read about arch, it would be well possible to define,
> say:

s/arch/tla/

arch is obsolete now, and replaced with tla.

tla is the only revision system that I know of (besides Bitkeeper) that
supports distributed repositories, which I think could be rather
important for selinux policy.

So I could maintain my own private repository, keep it up to date with
changes to selinux, while still maintaing a revision history of my
changes.

Sure, you can do this with CVS vendor branches, but this can get clumsy,
and CVS wasn't designed for this purpose.

The only question mark I have with tla, is that I have never seen a
conflict, and I don't know how easy it is to resolve conflicts.

There also are a few issues that take a bit of getting use to,
especially if you are use to CVS. For instance, you don't commit
individual files like in CVS, you commit a number of files in one go,
and the revision of the entire project gets incremented (eg.  similar so
a changeset in Bitkeeper or a commit operation in Subversion).

(then again, I haven't migrated from using arch to tla yet for my
projects either, but I will save that for another thread).
-- 
Brian May <bam@snoopy.apana.org.au>

--
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: policy under version control

[Colin Walters]

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

On Tue, 2003-12-02 at 04:59, Brian May wrote:

> arch is obsolete now, and replaced with tla.

"arch" refers to the protocol.  "larch" refers to the old shell-script
implementation that I think you're thinking of.

larch, tla, ArX and others are all implementations of the arch protocol.

> tla is the only revision system that I know of (besides Bitkeeper)
> that supports distributed repositories, which I think could be rather
> important for selinux policy.

Right; I think the primary reason it would be good is because changes
tend to bounce between several people as well as the NSA.  So there is
no clear "upstream".

> The only question mark I have with tla, is that I have never seen a
> conflict, and I don't know how easy it is to resolve conflicts.

You get fewer spurious conflicts, and the conflicts that do occur are
often easier to resolve because changesets are individually structured
and easy to manipulate.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: policy under version control

[Tom]

On Tue, Dec 02, 2003 at 08:59:15PM +1100, Brian May wrote:
> arch is obsolete now, and replaced with tla.

True.


> So I could maintain my own private repository, keep it up to date with
> changes to selinux, while still maintaing a revision history of my
> changes.

Exactly. I am, for example, still missing my subversion policy from the
default thing. Instead of buggering people to include it, I could
simply set it up in my own repository and be done.


> There also are a few issues that take a bit of getting use to,
> especially if you are use to CVS. For instance, you don't commit
> individual files like in CVS, you commit a number of files in one go,
> and the revision of the entire project gets incremented (eg.  similar so
> a changeset in Bitkeeper or a commit operation in Subversion).

I've been using Subversion for well over a year now with a small team
of developers, and those changes are really easy getting used to.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: policy under version control

[Andreas Schuldei]

* Tom (tom@lemuria.org) [031207 14:26]:
> I've been using Subversion for well over a year now with a small team
> of developers, and those changes are really easy getting used to.

russel, there seems to be a some people working together on this
allready. can you live with beeing a subversion-to-cvs gateway
for stephen smally and relay patches and corrections to im, if
you get the changes in subversion form?

everyone else:
are there public subversion repositories where people merge their
changes? could you send a list please? 

--
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: policy under version control

[Russell Coker]

On Mon, 8 Dec 2003 00:41, Andreas Schuldei <andreas@schuldei.org> wrote:
> * Tom (tom@lemuria.org) [031207 14:26]:
> > I've been using Subversion for well over a year now with a small team
> > of developers, and those changes are really easy getting used to.
>
> russel, there seems to be a some people working together on this
> allready. can you live with beeing a subversion-to-cvs gateway
> for stephen smally and relay patches and corrections to im, if
> you get the changes in subversion form?

Yes, I can do that.  I'm not sure what the best way of managing this is, I 
want to read every patch before accepting it, so I don't want anything 
automated at my end.

-- 
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: policy under version control

[Tom]

On Mon, Dec 08, 2003 at 12:44:59AM +1100, Russell Coker wrote:
> Yes, I can do that.  I'm not sure what the best way of managing this is, I 
> want to read every patch before accepting it, so I don't want anything 
> automated at my end.

Russell, my suggestion would be this:

Have one "default policy" repository, that only you a few people can
write to, but other people can use as a base.

I'd also set up a public repository with world-write access,
essentially as an easy place to contribute.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: policy under version control

[Tom]

On Sun, Dec 07, 2003 at 02:41:14PM +0100, Andreas Schuldei wrote:
> russel, there seems to be a some people working together on this
> allready. can you live with beeing a subversion-to-cvs gateway
> for stephen smally and relay patches and corrections to im, if
> you get the changes in subversion form?
> 
> everyone else:
> are there public subversion repositories where people merge their
> changes? could you send a list please? 

We were talking about tla/arch, not subversion. :)

I have several Subversion repositories running, and I have played with
tla before. I would be willing to set up a public tla repository. In
fact, I'm already working on it, I just have some trouble getting the
WebDAV part running.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: policy under version control

[Colin Walters]

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

[We're kind of drifting offtopic here; if anyone has questions about
arch/tla, gnu-arch-users@gnu.org is a better place]

On Tue, 2003-12-02 at 02:08, Tom wrote:

> That's exactly where a more modern replacement of 20-year-old CVS would
> help. From what I read about arch, it would be well possible to define,
> say:

When I was maintaining my own policy tree over the summer, I used arch. 
(As I do for everything nowadays).  It's in 

Archive: walters@debian.org--2003-debian 
Location: http://arch.verbum.org/arch-debian

if you're curious.

> This is Tom's Whatever Policy Repository
> all macros and these and these file_contexts and domain/program files
> are identical to the upstream policy (*)
> these 2 files are different (**)
> these 4 files replace their counterparts upstream
> these 12 files are new
>
> (*) this definition is very much like a network-aware symlink
> (**) very much like a diff, with a built-in pointer to the URL of the
> original

You shouldn't think in terms of changes to individual files with arch. 
All changesets in arch are atomic modifications to an entire tree.  
So you don't really explicitly define what files are identical or
whatever; instead, if you don't modify them, they simply aren't included
in your changesets.

Also, instead of thinking of the distributed nature as a "network-aware
symlink", I think the most important thing is that it's a truly global
namespace of changesets (composed mostly of just simple patches), which
have archives which map to URLs.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: policy under version control

[Tom]

On Tue, Dec 02, 2003 at 09:58:45AM -0500, Colin Walters wrote:
> if you're curious.

I am :)


> You shouldn't think in terms of changes to individual files with arch. 
> All changesets in arch are atomic modifications to an entire tree.  
> So you don't really explicitly define what files are identical or
> whatever; instead, if you don't modify them, they simply aren't included
> in your changesets.
> 
> Also, instead of thinking of the distributed nature as a "network-aware
> symlink", I think the most important thing is that it's a truly global
> namespace of changesets (composed mostly of just simple patches), which
> have archives which map to URLs.

Thanks, you explain this much better than I could. Someone else said
off-list that he'd be interested. I think I'll just give it a shot and
try to set up an arch repository on nox.lemuria.org this week.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: policy under version control

[Tom]

> Thanks, you explain this much better than I could. Someone else said
> off-list that he'd be interested. I think I'll just give it a shot and
> try to set up an arch repository on nox.lemuria.org this week.

I've got a repository, but the webdav access doesn't work. Anyone got
experience with arch, webdav, apache2 ?


-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: policy under version control

[Karl MacMillan]

On Mon, 2003-12-01 at 14:28, Tom wrote:
> On Mon, Dec 01, 2003 at 10:13:35AM -0500, Stephen Smalley wrote:
> > There is already a sourceforge CVS tree, and patches can be posted to
> > the selinux list.
> 
> The problem I see with read-only CVS and a post-to-mailinglist approach 
> is that it's non-trivial to maintain various sets of the same policy.
> 
> It seems that in the long run we won't be able to do with a single
> default policy. We'll need a couple, or a modular approach. Something
> very much like Debian's tasksel or other tools for other distributions
> where you have 5-10 fields you can check what your machine is going to
> be, and the relevant policy is then assembled automatically.
> 
> 

We are working on some general mechanisms to address this problem. The
first is the ability to define booleans in policies that can be changed
at runtime. This will allow you to turn on and off TE rules based on the
values of the booleans. We posted some messages about this in the past
and we are going to release a working snapshot of this in the next few
days.

We are also working on binary policy modules, which more directly
address what you are wanting I think. This will allow you to create
small binary policy modules separately from a base policy. This is
primarily for the purpose of adding or removing policy components for
specific applications. The advantages of this system are that the
requirement for the policy source and checkpolicy is removed, there will
be language extensions to make the policy modules more loosely coupled
to the core policy (i.e. 1 module will potentially work with a variety
of base policies), and there will be provisions to handle labeling on
installation or removal of the policy modules. Hopefully we will be able
to post some more information about this in the near future (we are in
the design phase of this project).

Karl

-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com
(410) 290-1411 x134


--
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: policy under version control

[Serge E. Hallyn]

> We are also working on binary policy modules, which more directly
> address what you are wanting I think. This will allow you to create
> small binary policy modules separately from a base policy. This is

For DTE, I "compile" a set of modules into policy.  Each module (ie ssh)
can define related types and domains (ie ssh_t, ssh_et, ssh_socket_t, ssh_d).
In order to facilitate concise (and precise) inter-module access rules, types
and domains can each be specified by:

   their explicit name (ie sbin_t and bin_t)
   hierarchy (so you can call bin_t and sbin_t binaries.bin_t and
      binaries.sbin_t, then talk about access to binaries.*, but still
      talk about just bin_t)
   group (there can be groups of types, and groups of domains)
   "all"

Priority of listed access rules goes up with precision, so
Domain my_domain
   access all none
   access binaries.* rx
   access bin_t rwx
End

gives the intuitive result.  Also, "incoming" access rules take
priority over "outgoing" access rules, so if we have a wu_ftpd domain
giving itself write access to root_t, but root_t itself denied that
access, then wu_ftpd will not have that access.  (again to give the
intuitive result, not in any misguided attempt to "protect" from a
module)

Modules are, then, intended to be pretty much standalone, so you do
just apply a module to a base policy.  Some additional hooks check
for maintenance of desired constraints (anything you care to implement,
but currently there's only a modified version of BLP) accross module
application.

I can see the value (for selinux) in sending out binary policy modules,
but it seems that easily modifiable source modules should be more
useful.  I've been meaning for quite some time to implement this kind
of thing to work with selinux, but I just keep getting sidetracked...

I also keep debating whether it would be simple enough to implement
with the current selinux policy system.  It seems flexible enough that
it should be.

-serge

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