Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!philmtl!philabs!linus!jp
From: jp@linus.UUCP (Jeffrey Picciotto)
Newsgroups: comp.windows.x
Subject: Re: Security extensions to X
Message-ID: <83040@linus.UUCP>
Date: 12 Dec 89 20:54:55 GMT
References: <8912091949.AA02514@kanga.lcs.mit.edu>
Reply-To: jp@linus.UUCP (Jeffrey Picciotto)
Organization: The MITRE Corporation, Bedford MA
Lines: 60


> One possibility is to pursue a similar tact as that used by SUN for
> secure NFS.  Use DES (or better) encrypted TCP/IP, each pair of nodes for
> which secure communication must occur share a key for the link.

Really, this is network security.  Clearly, if you run X on a network, you'll
need to provide network security, but this is true of any networked software,
not just X.

Developing a trusted version of X (e.g., at the TCSEC B level, or a CMW
version) requires a very different kind of security.  Like someone mentioned:
objects have to be labeled with sensitivity labels (and information labels for
CMWs), objects need to be subject to discretionary access controls, and so on
as per the TCSEC/CMWREQs.

The original poster asked if work is being done in this area.  The answer is:
yes, a variety of companies are working the problem.  In fact, 4 companies
currently have govt contracts to develop B-level/CMW-compliant systems running
X.  MITRE, also, is looking into the problem.  Presumably others are too.

What are the issues?  Some obvious ones are:

	what are the X objects?

	how can DAC/MAC/IL policies be implemented on these objects?

	how can a trusted path mechanism be implemented?

	how can the auditing requirements be interpreted and met in
	a useful fashion in X?

	CMWREQs require that user input be labeled.  How can this be
	done in a non-confusing way taking into account the input focus
	and keyboard/mouse grabs, &c?

	what's a useful & meaningful least privilege mechanism in X?

	how can all this be done without modifying the X protocol or
	breaking (at least, as little as possible :-) existing clients?

	can any of this ever be standardized enough to allow for truly
	interoperable heterogeneous environments?

Someone said:

	"There is growing interest within various members of the Consortium
	 for an extension that will provide at least B2 security."
	
I think a better phrasing might be: "there's a growing interest in security
within the Consortium."  The problem is that specifying interfaces does not
guarantee security.  Especially B2-level security.  (B2 will be extremely
difficult to achieve using X.  The two main problems being, IMHO, the covert
channel and the system architecture requirements.)

Anyway, people *are* thinking about the issues.  As one such person, I'm
certainly willing to discuss the problems/possible solutions.

--jeff picciotto
{*}!linus!jp
jpicc@mbunix.mitre.org