Emacs major mode for policy editing

Emacs major mode for policy editing

[Eamon Walsh]

My name is Eamon Walsh; I recently joined the NSA selinux team.
I will be working on putting policy enforcement into XFree86.

I've attached a simple Emacs major mode definition for policy editing.
It highlights keywords, comments etc. in different colors.

Drop the file into your Emacs library (/usr/share/emacs/site-lisp on
RH9).  Add the following to your ~/.emacs: 
(load-library "selinux-policy")
and make sure you have font-lock mode turned on:
(global-font-lock-mode t)

In Emacs, use M-x selinuxpolicy-mode to enter the mode.  .te files go
into in automatically.

Enjoy,
Eamon W.


--
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: Emacs major mode for policy editing

[Chris PeBenito]

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

On Thu, 2003-09-25 at 10:36, Eamon Walsh wrote:
> My name is Eamon Walsh; I recently joined the NSA selinux team.
> I will be working on putting policy enforcement into XFree86.

Cool, thats great.  I've been approached by a few Gentoo users who
wanted to try SELinux on their workstations over the last few months.  I
wouldn't mind adding it onto my own either.  I'm interested to see how
things pan out.

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer, SELinux
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243

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

Re: Emacs major mode for policy editing

[Bill Laut]

On Thursday 25 September 2003 11:36 am, Eamon Walsh wrote:
> My name is Eamon Walsh; I recently joined the NSA selinux team.
> I will be working on putting policy enforcement into XFree86.
>

When do you anticipate having security-enhanced X completed?

Bill


--
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: Emacs major mode for policy editing

[Bill Laut]

On Friday 26 September 2003 06:09 pm, you wrote:
> On Fri, 2003-09-26 at 17:43, Bill Laut wrote:
> > On Thursday 25 September 2003 11:36 am, Eamon Walsh wrote:
> > > My name is Eamon Walsh; I recently joined the NSA selinux team.
> > > I will be working on putting policy enforcement into XFree86.
> >
> > When do you anticipate having security-enhanced X completed?
> >
> > Bill
>
> I just came on board and have been studying the problem; no definite
> implementation strategy exists yet.
>

I've been looking at it off and on for a few months.  I used to heavily hack X 
about 10 to 13 years ago, so this is largely "old stomping grounds" for me.  
Bringing myself up to speed on the internals of SELinux is the bigger 
challenge to me.  

>
> We talked with an experienced X person who claims he can solve the
> problem (which consists of two parts: policy enforcement in the X server
> and "labeling" of windows by the window manager) in six months.  This
> person might get hired as well as myself.  I will be working on this for
> 8 months or so.
>

An estimate of six months strikes me as "contingency planning" and which is 
certainly acceptable.  My personal implementation schedule, however, will be 
considerably more aggressive.

Of course, I'm not under contract to NSA and therefore you cannot depend on me 
hitting my time estimate.  If I'm successful, great!  My stuff will get 
released under the GPL for all to benefit.  If not, well, you have eight 
months to get it working.

>
> I have been looking at the X Security extension and trying to figure out
> if this code could be used as a starting point.  It seems pretty good so
> far, but I'm concerned about how other extensions interact with it
> (notably Xag and XTrap).
>

I think you're going too far up the tree.  You want to be closer to the root.  

X has a well-defined protocol interfacing the client's Xlib and the XServer 
via a "Transport Layer" that implements the Event and Request Queues.  In 
fact, with some implementations (such as DECWindows under VMS) there is a 
bona fide formal Transport Layer in which you can implement your own 
Transports to handle whatever abstraction you want to speak X over.

Everything going into and out of the XServer (with the obvious exception of 
the monitor, keyboard, and mouse, etc.) goes through those Queues via that 
Transport layer.  Therefore, it makes more sense to install the "gatehouse" 
at the XServer's main dispatcher because (1) we can enforce policy on ALL 
Requests and Events to/from ALL Xclients, local and remote; and (2) in so 
doing minimize the changes needed to XFree86.

As an "extra homework assignment," this could also be a good excuse to go 
through the code to hunt down potential buffer overruns and nail them in the 
Gatehouse, but that could be for another topic.

Of course, there will undoubtedly be some things that won't fit this paradigm 
and will have to be handled within their own modules.  However, the majority 
of tasks will fit within the "gatehouse" and so it makes sense to "kill as 
many birds with one stone" as is possible.

>
> I think the hardest part will be cut & paste, which seems to be a big hack
> in X overall.
>

I'm suspecting it will depend on how "messy" you want to get with it.  
Personally, for now, I don't think it will be a major issue.

The scenario I consider a paradox is how to enforce policy on remote clients.  
To wit, where all the clients are local on the same box with the XServer, it 
is trivial to independently authenticate each client via the kernel.  Kind of 
like Kerberos' use of the "trusted third-party" model, but where our 
third-party is the kernel itself.  Piece of cake:  The XServer doesn't use 
anything the client could possibly say about itself to decide whether or not 
to allow a given Request to be accepted, because the authenticating data was 
never within the client's reach to possibly taint.

On the other hand, what do we do with remote clients connecting via the 
network?  Anything more than a summary policy decision will require 
authentication data not stored on the XServer's box.  How do we protect 
ourselves from being spoofed?

Furthermore, this requirement, in turn, could conceivably lead into 
discussions of crypto (to protect the TCP stream) that NSA employees may or 
may not be allowed to discuss within a mailing list.  This may be a point 
that an appropriate echelon should investigate and mention for our benefit at 
this project's outset, so that we don't violate any rules.

>
> Did you post to the list earlier this month and say you were also
> working on this problem?  Someone did and I lost the e-mail.
> Once the project gets rolling there will be more list traffic, for sure.
>
> --Eamon

Yes, I had posted to the list that I was working on Security-Enhanced X (or 
"s-ex," as Russell puckishly termed it) some time ago.

I have one other committment that I'm finishing this week, and then I can 
devote more time to s-ex.  In my last posting to the list I committed myself 
to delivering a first draft of an implementation strategy by mid-October, and 
I'm still shooting for that target.

The purpose of the document is to give everyone on the mailing list a chance 
to review it and identify errors, omissions.  Shoot arrows at it.  That sort 
of thing.  All contributions, ideas, suggestions are welcomed.  Then, once 
everything is identified I want to get started implementing the controls 
within X.


Bill


--
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: Emacs major mode for policy editing

[Russell Coker]

On Sat, 27 Sep 2003 12:09, Bill Laut wrote:
> Yes, I had posted to the list that I was working on Security-Enhanced X (or
> "s-ex," as Russell puckishly termed it) some time ago.

Surely I can't have been the first person to notice the SE-X acronym!

At this point I should mention that Security Enhanced X is an important 
development for Linux, it's something that we've been waiting far too long 
for, and when it's available I'm sure we won't be able to get enough of it.

We just have to make sure that it's correctly implemented to avoid viruses and 
unwanted child processes.

-- 
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: Emacs major mode for policy editing

[Bill Laut]

On Saturday 27 September 2003 06:24 am, Russell Coker wrote:
> On Sat, 27 Sep 2003 12:09, Bill Laut wrote:
> > Yes, I had posted to the list that I was working on Security-Enhanced X
> > (or "s-ex," as Russell puckishly termed it) some time ago.
>
> Surely I can't have been the first person to notice the SE-X acronym!
>

Yours is the first use of it that I'm aware of.  I probably noticed it at some 
unconcious level, but didn't pay it much attention until you used it.  One of 
the signs of approaching middle age on my part, no doubt!  :-(

>
> At this point I should mention that Security Enhanced X is an important
> development for Linux, it's something that we've been waiting far too long
> for, and when it's available I'm sure we won't be able to get enough of it.
>

I couldn't agree with you more.  That's why, for my contribution, I want 
everyone who is interested to review it and tell me where I'm in error, or 
where something could be better designed, so that what I eventually release 
to the group is a polished gem.

I have no ego problems with peer review/criticism whatsoever.

>
> We just have to make sure that it's correctly implemented to avoid viruses
> and unwanted child processes.
>

That's also why I threw in the reference to "extra homework" in my previous 
post.  For example, this could be a good excuse to go through XFree86 and 
insure that there aren't any unrecognized buffer-overflow vulnerabilities.  
It would be embarassing to say the least to release SE-X, only to have it 
contain exploitable BO vulnerabilities--the very thing that SELinux is 
advertised as protecting against.

The tact I intend to take is to break the implementation down into small, 
manageable pieces that can progressively be built upon, until the project is 
finally completed.  This should help making the "lessons learned" from each 
piece easier to integrate as well as speed up the overall implementation.

Bill


--
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: Emacs major mode for policy editing

[Russell Coker]

On Sun, 28 Sep 2003 06:24, Bill Laut wrote:
> > At this point I should mention that Security Enhanced X is an important
> > development for Linux, it's something that we've been waiting far too
> > long for, and when it's available I'm sure we won't be able to get enough
> > of it.
>
> I couldn't agree with you more.  That's why, for my contribution, I want
> everyone who is interested to review it and tell me where I'm in error, or
> where something could be better designed, so that what I eventually release
> to the group is a polished gem.
>
> I have no ego problems with peer review/criticism whatsoever.

I agree that extensive review is a good thing.  One of the reasons for my work 
on UML and SE Linux is so that images of SE Linux machines can be exchanged 
for review.  I'm sure that exchanging images of Security Enhanced X will 
become a popular past-time for many people.

> That's also why I threw in the reference to "extra homework" in my previous
> post.  For example, this could be a good excuse to go through XFree86 and
> insure that there aren't any unrecognized buffer-overflow vulnerabilities.
> It would be embarassing to say the least to release SE-X, only to have it
> contain exploitable BO vulnerabilities--the very thing that SELinux is
> advertised as protecting against.

Absolutely!  However it should be noted that SE Linux has a very expressive 
configuration language which allows detailed control over what is allowed.  
If an administrator desires Back-Orifice access to their network then the 
Security Enhanced X configuration will surely allow them to enable it.

-- 
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: Emacs major mode for policy editing

[Bill Laut]

On Saturday 27 September 2003 11:43 pm, Russell Coker wrote:
> On Sun, 28 Sep 2003 06:24, Bill Laut wrote:
>
> > That's also why I threw in the reference to "extra homework" in my
> > previous post.  For example, this could be a good excuse to go through
> > XFree86 and insure that there aren't any unrecognized buffer-overflow
> > vulnerabilities. It would be embarassing to say the least to release
> > SE-X, only to have it contain exploitable BO vulnerabilities--the very
> > thing that SELinux is advertised as protecting against.
>
> Absolutely!  However it should be noted that SE Linux has a very expressive
> configuration language which allows detailed control over what is allowed.
> If an administrator desires Back-Orifice access to their network then the
> Security Enhanced X configuration will surely allow them to enable it.
>

This is to clarify the paragraph that you commented upon.  When I used the 
term "BO" I was abbreviating my earlier usage of "buffer-overflow."  I 
recognize that BO is the common abbreviation for "Back Orifice, and therefore 
I should have used a more discriminating abbreviation.  Therefore, in the 
future when I abbreviate "Buffer-Overflow" I will use "BuOv."  

I agree with what you said about an administrator -overtly- desiring to enable 
a Back Orifice; there's no way to prevent it, and in fact it's not our place 
to tell them they can't.  Given its size and complexity, what I'm pondering 
is the potential for as-yet undetected BuOv vulnerabilities in the existing 
XFree86 code.  Obviously, an appropriate policy will fence in a compromised 
Xserver, so long as it wasn't installed SUID.  eg, the Request passes policy 
enforcement, only to then be dispatched into a module with an unforeseen BuOv 
that allows a malicious Xclient to compromise the Xserver (or another Xclient 
with a BuOv in Xlib that was installed SUID).  That's why I was wondering if 
it would be appropriate to inspect XFree86 for boundary checking of all 
incoming client messages.

Bill


--
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: Emacs major mode for policy editing

[Bill Laut]

On Sunday 28 September 2003 01:25 pm, Bill Laut wrote:
>
> Obviously, an appropriate policy will fence in a compromised Xserver, so
> long as it wasn't installed SUID.  
>

Arg!  That's what I get for rushing through my email.  Mea culpa.  Sorry about 
that.


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