Re: X Windows discussion

[Bill Laut <wlsel@verizon.net>]

On Wednesday 01 October 2003 01:34 am, Russell Coker wrote:
> On Wed, 1 Oct 2003 06:31, Bill Laut wrote:
> > I do have a concern about the effects on system performance.  Unlike
> > general policy enforcement decisions, the X system presents a scenario
> > where multiple tests may have to be made before a decision can be
> > rendered and/or where multiple tests may have to be interleaved to reach
> > a "composite" decision (a screen snapshot, for example, comes immediately
> > to mind in both cases).
>
> Are many people running systems where screen capture speed is a bottleneck?
>

No.  My citation of the screen capture was intended to illustrate where 
multiple decisions would have to be made before a "composite" decision could 
be reached.  EG, which windows is the screen capture allowed to record.  That 
sort of thing.

A more realistic system overhead comparison would be to ask the question, "how 
much overhead would X impose versus, say, copying a large file where every 
file-I/O operation is being vetted by the kernel AVC?"  Just that question by 
itself answers my concerns.  But, as I said previously, these concerns are 
purely speculative at this point.

>
> > > The existing SELinux policy in the kernel controls who can connect to
> > > the X server.
> >
> > I was under the impression that the existing SELinux policy only had
> > granularity to the IP/port address, not to the client's source context
> > (unless labeled networking is in effect).  Has this changed?
>
> For local connections we control access to the Unix domain socket and to
> the TCP port.  For remote connections the only sensible thing to do is to
> use ssh tunneling.  You just have to avoid doing "ssh -X untrusted-host"
> (you would be amazed how many people try to do X forwarding from my play
> machine).
>

While ssh tunneling would (thankfully) encrypt the TCP stream (and *should* be 
employed for that purpose), it has no means of passing the client's security 
context to the server.  Let alone pass it to the server in a form that a 
malicious client couldn't spoof.

>
> As for labeled networking, requiring IPSEC is a difficult issue, many
> people have deployed networks with other systems and are not in a hurry to
> change.
>

Whoa, back up!  I didn't say we should mandate IPSEC.  That is something 
entirely different.  What I said was:

     "I suppose what I'm proposing is something like Labeled Networking with
     IPSec-like key negotiation, etc., but without it actually becoming a
     formal VPN."

What I'm envisioning is an enhanced version of the labeled networking support 
already extant within the SELinux suite.  It would transparently negotiate a 
session key with its counterpart on the peer as needed, and then exchange 
encrypted (with the session key) security contexts within the Options field 
of the IP header as the client and server communicate with one another, so 
that a security-aware server (X, in this case) would know -which- application 
on the client _via_the_security_system_calls_ was trying to connect to it, so 
that it could decide whether to accept that incoming connection request and 
if so then what access to grant the client.

In effect, we are "tunneling" (so to speak) security/authentication data from 
one kernel AVC to another within the IP Options field, and thereby know 
*nonreputably* WHICH client is truly attempting to connect with us.

Finally, let me *emphatically* state that SE-N (Security Enhanced Networking) 
is an -optional- convenience the user/administrator/whoever may or may not 
choose to build into their system.  Furthermore, it would not as yet rank 
very highly on my priority list, as we're still ironing out implementation 
issues on SE-X itself, before (maybe) jumping into SE-N.

Notwithstanding, as I'm proposing stuff I'm looking way, way down the road to 
what features and options would really be useful.  To that end, what I'm 
seeing in SELinux *in its current form* is the premiere security system for 
securing -existential- Linux boxes:  Boxes whose world exists only within 
themselves.  But what happens when you want to link multiple boxes together, 
but spread the security power of SELinux across all of them?  This is where 
SE-N comes in.

Let's use SE-X as an example.  To use SE-N with SE-X, I'm conjecturing that 
you would exchange public keys between your X workstation and the various 
boxes whose clients will be connecting to your Xserver, so that they can 
mutually authenticate each other to its counterpart when session keys need to 
be created to support networked communication (IE, a client wants to 
establish a stream to a server.  The SE-N layer on the client machine 
determines that a session key is needed with the server machine, so before 
the client's SYN is sent the client SE-N negotiates a session key with the 
server SE-N.  Now, the client's SYN is sent, with the appropriate security 
context encrypted within the IP Options field.  If there is no public key on 
file for the server, then the client SYN is sent as "unlabeled traffic.").  

You can decide which hosts are authorized to connect to your box's services (X 
being one of possibly many) based on such criteria as:  (1) Unlabeled vs 
labeled traffic, and if labeled (2) which policy-defined clients are allowed 
to connect to which services.  And all of this can be defined within policy.

You posted this question in a different email this evening/morning:

   "The problem we need to solve is how to manage different X connections
     having different privs.  If I login to a trusted-host and want to run a
     trusted application and an IRC client, then how do I make sure that my
     trusted application's X window is protected from my IRC client?"

SE-N is the answer to your question.  The exchanging of keys is what defines 
the client host as being trusted, because when you run the "trusted 
application" ("trusted" as defined in the trusted-host's policy) and then run 
the IRC client, the trusted host's SE-N will establish a "tunnel" of sorts 
within the IP Options field with your workstation so that the Xserver on your 
workstation can distinguish the differing incoming Xclients.

In fact, you wouldn't even need SSH to establish the initial connections.  For 
example, let's conceptualize a client/server suite:  The server clones off 
whatever Xclients are requested of it, pointing them to the correct Xserver 
workstations they should connect to (your workstation, in this example); and 
the server is installed on all the trusted hosts whose Xclients you want 
connecting to your workstation's Xserver.

The client is a simple program on your workstation that establishes a TCP 
stream to the server installed on the target trusted host; and all it does is 
tell the server to clone the requested Xclient, pointing its DISPLAY to your 
workstation.

The client and server have their own domains within policy, so when you 
locally run the client (1) your workstation's SE-N first negotiates a session 
key with the trusted host's SE-N before passing the SYN--with the local 
client's security context encrypted in the IP Options field--to the trusted 
host's TCP layer (and from there to the port the server is listening on).  

(2) The server receives the SYN, examines your client's security context (as 
relayed in the IP Options field), determines your client is authorized to 
access it, and so issues the ACCEPT to your SYN.

(3) Your client requests the server to clone the target Xclient.  The server 
determines your client is authorized to request it, and proceeds to clone it.

(4) The Xclient tries to establish a TCP stream to port 6000 on your 
workstation.  A session key has already been established from (1), so the 
Xclient's source context is encrypted into the IP Options field along with 
SYN.  

(5)  The Xserver receives the SYN, determines via policy that the trusted 
host's Xclient is authorized to connect to it, and so permits the connection 
to be made.  All resources created by the Xclient (such as windows, widgets, 
gadgets, glyphs, whatever ad infinitum) are labeled with that Xclient's 
source security context.

(6)  Now, should the remote IRC client try to access your trusted remote 
application, the Xserver can make policy-based decisions on whether or not to 
allow the trusted Xclient's resources to be examined by another Xclient. 

Anyway, I could go on and on, but it's 4:15am over here and I'm ready to keel 
over.  I'll answer your other post in the morning.  In short, (imo) SE-N has 
-tremendous- potential to leverage the power of SELinux beyond its current 
existential limitations to include Beowulf clusters, load-balancing arrays, 
etc., etc., etc.  

And SE-X is the likely "killer app" to -gently introduce- this power to the 
Linux community.

>
> The incompatabilities for administration tools for the different
> implementations of IPSEC in the Linux kernel make this more difficult. 
> Also there's the issue of firewalls that block IPSEC.
>

What I'm envisioning is a facility that borrows techniques from IPSec without 
actually becoming a formal IPSec.  In practice what ultimately we would see 
is a well-known port reserved to SELinux that SE-N's userland extension would 
listen on.  If (and I emphasize -IF-) the Linux community wishes to use this 
facility, they would individually have to configure their firewalls to allow 
SE-N to listen on that port.  They would also have to exchange/install pubic 
keys between cooperating boxes, as well as identify them within their 
policies.  Any resemblance to IPSEC ends at that point.

All that would be seen is the occasional traffic to SE-N's listener port.  
Everthing else would be "buried" in the Options field of the IP Header.

>
> If we demand that all networked SE-X users have IPSEC and labeled
> networking running then we'll greatly delay any use of the technology.
>

Not at all.  They can choose to run -unlabeled- traffic, which then they are 
left to figure out for themselves which incoming Xclient connection requests 
are trustworthy.  Or, they can bring up SE-N and configure their policies to 
decide which Xclients on which trusted hosts to allow connection to their 
Xservers, and what those Xclients can do.

     "Oh, and by the way, you can also use SE-N to let your security-aware
     servers decide nonreputably which clients can connect to them, and what
     resources the server will grant access to."

After the Linux community gets SE-N working with SE-X (and which I'll insure 
won't be hard to do), they'll also see how easily they can integrate SE-N 
with their own soon-to-be security-aware servers (which is, after all, the 
end-game) to spread the power of SELinux across clusters and traditional 
client/server arrangements.  In fact, my example of the client/server suite 
to launch your "trusted app and IRC client" citation could be a useful 
example program to include with SE-N so as to illustrate SE-N's power to the 
Linux community. 

Anyway, it's now 4:31am and I'm probably becoming incoherent (again), so I 
will end this post now and resume with your other post in the morning.

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.