X Windows discussion

X Windows discussion

[Eamon Walsh]

[This continues the X discussion that was under the "Emacs major mode" thread]


On Fri, 2003-09-26 at 22:09, Bill Laut wrote:
> 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.

Some of the points I make below are taken from the document "Securing the X 
Window System with SELinux" ( http://www.nsa.gov/selinux/x11-abs.html ).  I'm
largely working from this document in terms of looking at the problem.


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


Why do you think the XSecurity extension isn't close enough "to the root?"  
It installs its own dispatch table and is thus positioned to see every request 
that comes in, including SendEvent requests.

I think that building on XSecurity is the way to go.  My impression so far
is that it has hooks in good places and that using it will reduce the
changes we have to make to the core server.  It will also look better if one
can say to the XFree86 maintainers "Here's a new security extension" than 
"Here's a bunch of new code for the dix and os layers."

There are some XSecurity fields in the Client structure that may be very
useful if we can store the security context in them and then get from an
arbitrary resource (GC, colormap, drawable, whatever) back to the client that
created it.  We could then do labeling with a minimum of new fields in the
internal X structures.

Some links to XSecurity documentation:
http://ftp.x.org/pub/R6.4/xc/doc/hardcopy/Xserver/secint.PS.gz
http://davinci01.man.ac.uk/aix433/x11/specs/pdf/security.htm


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


As a policy enforcer, the X server will have to be vetted for security holes.
I don't think we have to worry about that for now, however.  See Section 3.0
of the SElinux/X paper.

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


I'm afraid of Cut & Paste because I don't know much about it, yet.  There's
the old method of setting properties on windows to pass clipboard data and
do drag & drop, then there's Clip Extension, and I have a vague notion that 
the desktops are doing their own thing.  It's very much a moving target.

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

The existing SELinux policy in the kernel controls who can connect to the X
server.  All we have to worry about is what goes on over the connection once 
it's established.  

You're right about the authentication problem though.  We need a way of 
associating the security context of a client application with its objects in 
the X server.  Unfortunately, there doesn't seem to be an easy, secure way of 
doing this.  The client can't be trusted to send it over.  If there were a way 
of getting the remote security context from a (unix domain) socket, we could 
use that, but the kernel has to be involved somehow, and with functionality
that it doesn't currently have.  Unless I'm missing something.

The cop-out solution, and probably the only solution for remote clients, is
to treat all clients the same way.  This may be too inflexible: screen-shot 
applications, for example, would no longer be possible.

-- 
Eamon Walsh <ewalsh@epoch.ncsc.mil>


--
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: X Windows discussion

[Bill Laut]

On Monday 29 September 2003 08:00 pm, Eamon Walsh wrote:
> [This continues the X discussion that was under the "Emacs major mode"
> thread]
>
> On Fri, 2003-09-26 at 22:09, Bill Laut wrote:
> > 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.
>
> Some of the points I make below are taken from the document "Securing the X
> Window System with SELinux" ( http://www.nsa.gov/selinux/x11-abs.html ). 
> I'm largely working from this document in terms of looking at the problem.
>

Understood.  I've read that document as well.

>
> > I think you're going too far up the tree.  You want to be closer to the
> > root.
> >
> > [...]
>
> Why do you think the XSecurity extension isn't close enough "to the root?"
> It installs its own dispatch table and is thus positioned to see every
> request that comes in, including SendEvent requests.
>

I'm going through my notes to answer your question, but I seem unable to find 
it.  There was something about the XSecurity extension that stood out to me.

I'll get back to this point by Wednesday evening.  If I don't find it by then, 
I'll concede the point and we'll go your way.

>
> I think that building on XSecurity is the way to go.  My impression so far
> is that it has hooks in good places and that using it will reduce the
> changes we have to make to the core server.  It will also look better if
> one can say to the XFree86 maintainers "Here's a new security extension"
> than "Here's a bunch of new code for the dix and os layers."
>

>From a political consideration I agree that XSecurity will be easier to sell, 
no doubt about it, unless a valid technical explanation is made.  It 
certainly meets the objective of being less intrusive.

>
> There are some XSecurity fields in the Client structure that may be very
> useful if we can store the security context in them and then get from an
> arbitrary resource (GC, colormap, drawable, whatever) back to the client
> that created it.  We could then do labeling with a minimum of new fields in
> the internal X structures.
>
> Some links to XSecurity documentation:
> http://ftp.x.org/pub/R6.4/xc/doc/hardcopy/Xserver/secint.PS.gz
> http://davinci01.man.ac.uk/aix433/x11/specs/pdf/security.htm
>

One of the things I'm currently sketching out is a means to implement this, 
using advice that Stephen posted 8/29/03.  Email me off-list if you want me 
to forward you a copy.  In a nutshell, he suggested (1) implementing a 
userspace AVC, (2) extentions to the socket API so the Xserver can obtain the 
security contexts of the local clients, and (3) a notification interface for 
when the policy is changed.  His recommendations paralleled the conclusions I 
was reaching, and should be straightforward to implement.

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).  
Additionally, X will probably induce greater enforcement overhead because all 
events--mouse movements, keystrokes, cursor blinking, etc.--get shoveled back 
and forth between the Xserver and whatever client currently has focus, as 
well as whichever clients have requested event notification (ie, the mouse 
moving through a client's window).

Per Stephen's advice, we could start off with a trivial port of the kernel 
AVC, but before we make a final committment I think it may behoove us to 
spend some time optimizing the AVC for the concerns I've listed above.

Does this seem reasonable to you?

Also, I should note that I am currently learning the internals of the kernel 
AVC implementation and in the process I wouldn't doubt that I'll "discover" 
its efficiency is already maximally optimized, thereby rendering my concerns 
moot.   I mean no disrespect to the SELinux Team by implying the AVC *could* 
be improved upon.  My concerns are merely speculative at this point.

>
> > 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.
>
> As a policy enforcer, the X server will have to be vetted for security
> holes. I don't think we have to worry about that for now, however.  See
> Section 3.0 of the SElinux/X paper.
>

Agreed.

>
> I'm afraid of Cut & Paste because I don't know much about it, yet.  There's
> the old method of setting properties on windows to pass clipboard data and
> do drag & drop, then there's Clip Extension, and I have a vague notion that
> the desktops are doing their own thing.  It's very much a moving target.
>

I agree that the desktop managers do cloud it, since their clipboards are not 
within X.  The others could be handled via the Request Queue, but as I think 
about it I'm now not certain about the Clip Extention.

Yeah, this is going to require more digging.

I anticipate that SE-KDE and SE-Gnome will likely follow after the successful 
conclusion to SE-X.

>
> > <discussion of local clients snipped>
> >
> > 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?
>
> 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?

>
>  All we have to worry about is what goes on over the connection
> once it's established.
>

Unless we mandate something like labeled networking, how do we determine the 
remote client's source context so that we can match its incoming Requests 
against the Xserver's policy?

*blink*  Labeled Networking?  Hmmm.....

I haven't yet closely scrutinized Labeled Networking, so what I'm about to 
suggest could be in error.  That said, labeled networking appears to be an 
ideal foundation although it would require some modifications.  Notably, (1) 
a finer granularity is needed so that labeled and unlabeled traffic can be 
simultaneously accepted and distinguished where applicable within the policy.  
eg, the current behavior of dropping unlabelled packets would have to be 
discontinued, so that "ordinary" traffic (such as an outgoing connection to 
an POP3 or web server) can occur while receiving labeled traffic intended for 
(among others) the Xserver.  (2) The labels themselves would have to be 
encrypted end-to-end by the kernels (or a trusted userspace extention), so 
that they are both kept out of reach of the client, and using a session key 
negotiated with an acceptable asymmetric ("public key") cipher so that a 
malicious user could not spoof the labeling via a raw ip socket.  (3)  We 
cannot include the labeling within any Xprotocol data structures nor the TCP 
stream itself, because that exposes it to possible userspace spoofing.  
Ideally, the encrypted label is applied in IP after the sender's TCP layer 
and processed/removed before the receiver's TCP layer.

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.  Assuming both the client and server boxes are running LN, this will 
allow us to identify the source context of who is attempting to connect to 
the Xserver before the connection is accepted, and afterwards to let the 
policy determine what access to permit on a per-Request basis.

>
> You're right about the authentication problem though.  We need a way of
> associating the security context of a client application with its objects
> in the X server.  Unfortunately, there doesn't seem to be an easy, secure
> way of doing this.  The client can't be trusted to send it over.  If there
> were a way of getting the remote security context from a (unix domain)
> socket, we could use that, but the kernel has to be involved somehow, and
> with functionality that it doesn't currently have.  Unless I'm missing
> something.
>

I think that (for lack of a better term) "Enhanced Labeled Networking" as 
described above deserves to be considered.  LN already stores the label in 
the IP Options field; we merely need to harden it for transit over untrusted 
networks.

X may well be the "killer application" for labeled networking.

If this seems like a plausible solution, then we may also want to consider 
extending Labeled Networking to include some sort of mapping abstraction 
between heterogenous but cooperating systems, because I'm skeptical that all 
cooperating X systems can be counted on to have homogenous policies.

Of course, this doesn't deal with the (imo) "bugaboo" of networked X sessions, 
namely unencrypted TCP streams.  Since the kernel now comes with a 
crytographic API, perhaps ELN can be extended to encrypt everything.

Does this seem like a reasonable approach to dealing with remote Xclients?

>
> The cop-out solution, and probably the only solution for remote clients, is
> to treat all clients the same way.  This may be too inflexible: screen-shot
> applications, for example, would no longer be possible.
>

If we employ ELN, the policy can then distinguish between labelled and 
unlabelled clients, and so the "cop-out solution" instead becomes the default 
solution.

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: X Windows discussion

[Russell Coker]

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?

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

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

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.

-- 
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: X Windows discussion

[Bill Laut]

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.

Re: [selinux] Re: X Windows discussion

[Magosányi Árpád]

A levelezőm azt hiszi, hogy Russell Coker a következőeket írta:
> Are many people running systems where screen capture speed is a bottleneck?

I am not in that set, if it does matter:)

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

No. What if my environment have proper physical security, and consists
of one or more trusted hosts being on the same switched network (for
example I use the multilevel packet switch certified TCSEC A1 :), and
some untrusted hosts being either on the same switched network or
at the far end of some router or firewall? Or -horribile dictu-
my site is connected to other similar enclaves through ipsec or
ssl channels, which channels end in a firewall/guard which is able
to properly label the traffic either through CIPSO or RIPSO,
or putting source tcp ports/ip addresses to predefined
intervalls/values?

The above is a set of assumptions which can be more or less easily
satisfied (well, me buying an A1 switch was just a joke, but if you
have a spare one, I will give you my postal address ;). With this
set of assumptions you do not have to need X forwarding.

Anyway, the main point here is not cryptography, but authentication.
And authentication should be done by Xauthority, I think.

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

Yes, and even naked cipso/ripso are not a real option.

____And here comes the important part:____

Having labels communicated to the packet filter IS an option which can be
relatively easily done, and can be used for communicating labels in a
multitude of ways through nodes.
Here are some scenarios which can be done if labels are translated to
netfilter marks:

1. outgoing packets can be SNAT-ed to either some port ranges or source
addresses based on label. In this way the other end can directly attach
the appropriate label to the traffic with the existing capabilities.

2. same for routing decisions to always go through trusted paths.

3. my favourite multilevel network protocol is plain old http(s),
with a X-security-level: or similar header. Wrap-in to this protocol
is easily implementable, wrap-out is actually implemented by Zorp.
We just need the labels, which can be picked up from the netfilter
mark, or with mechanisms given in point 1.

I guess that the main point is to have a way for the network mechanisms
to attach the label to the outgoing traffic in a manner which can be
handled by them by their usual habit.

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

And if we have iptable_semark module, we'll greatly speed it up...

-- 
GNU GPL: csak tiszta forrásbó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: [selinux] Re: X Windows discussion

[Bill Laut]

On Wednesday 01 October 2003 04:57 pm, Magosányi Árpád wrote:
> A levelezőm azt hiszi, hogy Russell Coker a következőeket írta:
> > Are many people running systems where screen capture speed is a
> > bottleneck?
>
> I am not in that set, if it does matter:)
>

I don't think anyone is, and which was Russell's point.  :-)

My original "concern" was nothing more than idle speculation, namely "is there 
a way we can somehow improve AVC's performance?"  A reflection of the ideal 
of never being satisfied with the status quo.

>
> > 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).
>
> No. What if my environment have proper physical security, and consists
> of one or more trusted hosts being on the same switched network (for
> example I use the multilevel packet switch certified TCSEC A1 :), and
> some untrusted hosts being either on the same switched network or
> at the far end of some router or firewall? Or -horribile dictu-
> my site is connected to other similar enclaves through ipsec or
> ssl channels, which channels end in a firewall/guard which is able
> to properly label the traffic either through CIPSO or RIPSO,
> or putting source tcp ports/ip addresses to predefined
> intervalls/values?
>
> The above is a set of assumptions which can be more or less easily
> satisfied (well, me buying an A1 switch was just a joke, but if you
> have a spare one, I will give you my postal address ;). With this
> set of assumptions you do not have to need X forwarding.
>

Not every site will reflect the model you list above.  In fact, I wager the 
majority of sites won't fit your description.  However, we have to design 
something that will satisfy the greatest possible audience.

The point of this is that we need to forward the Xclient's SID to the Xserver, 
so it can enforce policy regarding one Xclient's access of another Xclient's 
resources, etc.  Russell's advocacy of X-tunneling via SSH does make it the 
easiest to implement within existing network infrastructures (along with the 
obligatory mapping of type codes between heterogenous client/server 
policies).  

>
> Anyway, the main point here is not cryptography, but authentication.
>

Yes and no.

Yes, it is about authentication in the sense that you want to launch an 
Xclient on some remote host.  You first have to authenticate yourself to the 
remote host before you can launch the client back to your workstation.  SSH 
makes that trivial, and which is why Russell is advocating it.

But once you've authenticated yourself to the remote host, cryptography does 
enter the picture because the Xclient's SID has to be encrypted for its trip 
to the Xserver, otherwise we risk "leaking" some of the remote host's policy 
knowledge over potentially untrusted networks.  And, as the developers we 
have to anticipate and prepare for the worst-case scenario.  That's why I'm 
pushing crypto.

>
> And authentication should be done by Xauthority, I think.
>

Actually, with the advent of SE-X Xauthority will largely relegate to a 
vestigal status:  It'll still be there, but it will have become superfluous 
and redundant.

>
> > 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.
>
> Yes, and even naked cipso/ripso are not a real option.
>

But, again, I'm not pushing IPSEC.  I'm pushing the idea of storing the 
encrypted SID in the IP Options field so that (1) each packet is 
unambiguously labeled with its creator's SID, and (2) we minimize the 
potential for spoofing via a hacked SSH.

>
> ____And here comes the important part:____
>
> Having labels communicated to the packet filter IS an option which can be
> relatively easily done, and can be used for communicating labels in a
> multitude of ways through nodes.
> Here are some scenarios which can be done if labels are translated to
> netfilter marks:
>
> 1. outgoing packets can be SNAT-ed to either some port ranges or source
> addresses based on label. In this way the other end can directly attach
> the appropriate label to the traffic with the existing capabilities.
>
> 2. same for routing decisions to always go through trusted paths.
>
> 3. my favourite multilevel network protocol is plain old http(s),
> with a X-security-level: or similar header. Wrap-in to this protocol
> is easily implementable, wrap-out is actually implemented by Zorp.
> We just need the labels, which can be picked up from the netfilter
> mark, or with mechanisms given in point 1.
>
> I guess that the main point is to have a way for the network mechanisms
> to attach the label to the outgoing traffic in a manner which can be
> handled by them by their usual habit.
>

The proposed label is an encrypted SELinux SID transmitted from the Xclient's 
machine to the SE-Xserver, so that policy enforcement by the SE-Xserver can 
be applied to all Xclients, both local and remote.  Inserting the label into 
the IP Options field is the most logical way of "piggybacking" the label with 
the packet it represents.

Since the label is encrypted at the point of origin all routers between the 
client and server won't/shouldn't be able to interpret it (apart from a 
rudimentary header).  And even if the label wasn't encrypted, the values 
themselves and their interpretation are not a network function but are 
internal to SELinux.

Therefore, why would the underlying network infrastructure be concerned with 
the label's contents, provided it doesn't violate applicable RFCs?

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.