smith@PRC.Unisys.COM (Robert Smith) (12/07/89)
I am interested in finding out if any work is being done on extending X to
run in secure environments. By secure environments I mean in the military
sense. This includes limiting access to displays from remotes sites and also
things like restricting the display of data to a user with a security level
less than the level of the data (this implies some tagging of security levels
for each message sent to a display, I think).
I recall seeing at one time that the X Consortium had a task group looking at
security. Is any work coming out of that, or are any companies working on it?
If so, will it be donated to the Consortium? I'd also be interested in any
information on the problems/issues of extending X for secure environments.
Thanks in advance,
Bob Smith
Unisys
Internet: smith@prc.unisys.com
uucp: {liberty|psuvax1}!burdvax!smithjim@EXPO.LCS.MIT.EDU (12/08/89)
I am interested in finding out if any work is being done on extending X to run in secure environments. There is growing interest within various members of the Consortium for an extension that will provide at least B2 security. Given that the DoD has indicated that it would like to see secure window systems within the next 2-3 years, there will probably be an effort starting up in the next year or so. Contact your Consortium Representative (name sent under separate cover) for more information on how to get involved. Jim
brooks@maddog.llnl.gov (Eugene Brooks) (12/09/89)
In article <8912072350.AA26289@kanga.lcs.mit.edu> jim@EXPO.LCS.MIT.EDU writes: >There is growing interest within various members of the Consortium for an >extension that will provide at least B2 security. Given that the DoD has >indicated that it would like to see secure window systems within the next 2-3 >years, there will probably be an effort starting up in the next year or so. The issue has been given some thought here, the notion however is more general that just X and covers the whole issue of security of compartmentalized information on a network where any node can snoop for data without being seen. One possibility is to persue 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. TCP/IP packets evidently have source and destination address fields, and one simply encripts the data in the packet according to the agreed upon key between the two nodes. Each link between two nodes has a unique key, and the encription can be as nasty as is required for the data. Some "spy" node listening to the channel will only get hash. This is probably not fool proof. There are probably a lot of headers and other frequently occuring patterns in the data transferred by X. A good example would be commonly used background tiles and such. The classic weakness of having both the clear text and the encrypted text for a message does a good job a compromizing the key. It is probably sufficient for compartmentalizing information, where all people with physical access to the network are suitably cleared. brooks@maddog.llnl.gov, brooks@maddog.uucp
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (12/10/89)
One possibility is to persue 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.
You need something like this for environments in which you want to prevent
real-time network eavesdropping, but it doesn't help with the CMW requirements.
You need an extension so that you can isolate applications running at different
sensitivity levels. Since you have to make sure that people can't
inadvertantly change the classification of an object (such as by cutting info
from a Top Secret window and pasting it into an Unclassified one), you have to
make sure that applications running at one level can't determine what else is
running or interfere with it. This implies manditory and discretionary access
controls as well as sensitivity labels on every resource, support for a
trusted path to the operating system, interactions with grabs, font paths,
colormaps, and input focus.
Talk about being in a maze of twisty passages (and I consider myself basically
ignorant about all of this)....
Jimjp@linus.UUCP (Jeffrey Picciotto) (12/13/89)
> 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
guy@auspex.UUCP (Guy Harris) (12/16/89)
>One possibility is to persue 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. >TCP/IP packets evidently have source and destination address fields, and one >simply encripts the data in the packet according to the agreed upon key >between the two nodes. (Just so nobody gets the wrong idea, Sun's secure RPC doesn't encrypt data; it just encrypts credentials and verifiers to make it harder to spoof the server into thinking you're somebody you're not. The data still goes over the wire in the clear.)
jje@virtech.uucp (Jeremy J. Epstein) (12/19/89)
In article <83040@linus.UUCP>, jp@linus.UUCP (Jeffrey Picciotto) writes: > > > 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. Jeff is absolutely correct. Furthermore, Sun's secure NFS only encrypts the setup messages, not the actual transfer of data across the network. Therefore, although it's significantly harder to get into Sun's NFS now than it used to be, wiretapping is still quite effective since the data flows unencrypted. [This isn't directly relevant to the discussion of secure windowing, but I wanted to clarify the point] IMHO, Sun's 'secure' NFS is only secure by the loosest possible definition. > > 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. > Besides the four CMW vendors, there's other research. I'm working on a DARPA contract which will be building a secure X-Windows prototype under Mach. --Jeremy Epstein TRW Systems Division uunet!virtech!jje jje@virtech.uu.net -- Jeremy Epstein TRW Systems Division 2750 Prosperity Avenue FV10/5010