Messages in this thread | | | Date | Tue, 7 Mar 2000 10:35:18 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Capabilities |
| |
I've been under the wether lately and didn't see this earlier... I also didn't see a response later so I'll jump in with my opinions..
Linda Walsh <law@sgi.com>: > Albert D. Cahalan wrote: > > This is totally user-hostile, so it won't be used very much. > > The X server and window manager must be trusted software. > > This is what Trusted Solaris claims to do. Windows get marked > > with security data. Cut-and-paste is controlled. > --- > I'm curious here. I'm rather new to trust, so bear with me. > Lets say I am rated 'secret' -- anything I produce is tagged as > such. Also, as secret, I can only access programs and data of integrity=basic > (we don't want me willy-nilly running any old program sitting around)
First a little background that was missing from the earlier message- The "Trusted Solaris" bit is a reference to what sun is currently distributing for trusted operations on servers.
Sun also has a varient with X windows that is a "CMW" or Compartmented Mode Workstation. This contains the following security related software:
1. The X server - this special server carries the ability to trace security levels and attach security assignements to every "atom" created with the server. What this translates into is: a. any connection to the server has a label. b. This label is copied along with any atom created through that connection - hence any clipboard entry that is created recieves the label of the window it came from, which recieved its' label from the connection.
2. A trusted window manager - this special manager contains the ability to create windows of a different (higher) security level. The way this was implements (way back when I looked at it) was: a. the user requests a higer-than-current security level. The window manager reponds with a request for level, and if the user is permitted that level, it changes the "current" security level of the window manager. In the process of doing this the window manager informs the X server that the servers current level is the new level. This caused the X server to "gray out" the current display to show blocked access. b. The window manager drew a bar at the bottom of the screen with the current security level presented. Each time the level was raised, a new bar would be presented. This provided a "stacked" view of the levels that were activated.
At the time there was only one clipboard workspace available so tracking the level of the clipboard was simple - the only entry had the security level of the window that was the source of the data. Each level generated a new (empty) clipboard buffer.
Now for some fill-ins based on your "secret" authorizations:
if "secret" is the only level you are allowed, the you will be unable to change levels. So lets assume you are allowed "unclassified" (no security sensitive data whatsoever), "sensitive" (some privileged information but nothing catastrophic - say some preliminary product information) and "secret" (highly confidential and propritary design data/client non-disclosure data, and messages about an on-going company lawsuit:))
The CMW system would log you in at the lowest sensitivity level that is authorized by: 1. the system itself (it may not be allowed to process "sensitive" or "secret" data - this would prevent accidental disclosure. This may be set for workstations that are in a semi-public/public area like a conference room used for customer meetings to allow customers to reach their email servers...) 2. By the principle of "least privilege" you would get the minimum of your allowed levels.
Note: on non-CMW workstations this may be defined by having login do the following: a. prompt for login b. prompt for password/access key c. prompt for security level.
After validating the security level it starts X windows at that level. You could not request any other level (either higher or lower). This is the "totally user-hostile" environment referred to above. Sometimes this is eased by allowing the X user to terminate the X session (and server) back to a terminal session, request (and presumably get) a higher level. When X is started afterward it gets the new higher level.
> The first question is how would I start a window at say rating > 'unclassified' (assuming I have another signon or my signon has multiple > sensitivity ratings)?
Since the question makes some assumptions: 1. you already logged in (at the "public" level) 2. you switched to a higher security level ("secret").
If you now want to start a window at unclassified level - you would be blocked. The CMW is at a "secret" level and will not allow a lower level window to be created. (this would allow a "leak" of information from the higher level to lower level).
3. If the CMW is already at "unclassified" level, then nothing prevents you. It works just like it always did.
> Second question. I'm in a xterm type window in a shell. I > now type 'su' and 'su' to a user with a lower classification. The > Window is still owned by me, but in the window I'm running a lesser > classified user. Couldn't I cut and paste from the same window into > itself? Suppose I exit the lower classification (which produces information > of integrity=low). Now can't I cut/paste in the same window and upgrade > the integrity without checking if I have such authorization?
first the assumptions: 1. the CMW is at a "secret" level. 2. the xterm window is created at a "secret" level. 3. The "su" is on the CMW.
Then the CMW will prevent you from doing the su. Actually the way it works is that the Xterm (at secret) starts a shell which recieves its' level from Xterm. The "su" gets its initial level from the shell - which has "secret". The "switch user" would take the maximum level of the current process (the su), and the minimum of the authorized level of the new user. If the new user is not authorized at the current level, then the su recieves a "permission denied" error and an audit log event generated (security violation). The "way it works" is the same as on a server system using a serial line type of connection (wether it is telnet or something else, it would be the same).
> > Would being able to execute 'login' from the shell be > any different?
It would work the same way as "su".
> > The same could happen in reverse with a low classified user > su'ing or logging into a higher classified user, cat'ing out a file, then > returning to the lower classification to do the paste, thus > lowering data classification without authorization?
Yup. the "minimum of the current process and the desired user authorized level" blocks the change to a higher level. > > Another scenario -- I've su'ed to the lower sec user. My > background process I started earlier spits out 'secret' output. Will > it be interspersed with my unclassified output?
It wouldn't be permitted since the "su" to the lower user would have failed.
> > If my declassified user launches another Xapp, say a word > processor. Wouldn't it be possible for confusion to occur about which > windows are at what level and I might end up typing secret into > unclassified -- or is that just a case of 'user beware'?
Not "user beware". The X server has all windows labeled. The window manager also knows which windows have the levels since it can communicate with the X server about security labels. This is why the window manager has to be security aware and trusted.
With word processors lets make the following operational assumptions:
1. login started at unclassified. 2. CMW started some unclassified Xterm windows, which now display some data that will be added to a "secret" document. 3. the CMW is switched to "secret" level. 4. the word processor is started.
Paste is allowed from the unclassified Xterm window since the data is being transfered to a higher level. The clipboard buffer recieves the "maximum of the current level and the level of the source". That level would be "secret". The maximum used when the level of the action (the mouse selection) is done from a high level. Information leakage is prevented since the clipboard doesn't inform the application what level the target is going to be. The buffer cannot be accessed after the application (Xterm) "gives" it to the X server/window manager. > > Theoretically login and su don't know about Xwindows. Even > if they could somehow alter the current window's properties, I might > have my DISPLAY variable set to another host -- might it prove difficult > to find the right window to alter?
They dont need to (login/su). Lets show the environment for this type of connection: 1. the CMW is currently at "secret" level. 2. an Xterm is active with a shell (also both at secret).
Now - if the remote system being connected to supports multi-level security OR the remote system is labeled by the CMW at the "secret" level; then the connection to the system will be permitted. There are several limits that are supposed to be applied:
a. the connection can only be valid at a single level. If the remote system is multi-level then the remote system accepts the connection at the same level as the connection request (the telnet? which recieves its' level from the shell - which got its' level from the Xterm - which got its' level from the current level of the X server and window manger (secret). Changes to security level on the remote system is not possible (this is policy - not enforcable by software). b. If the remote system is not multi-level then any connection made to that system will be at the level assigned. The assumption being that all workstations are CMW, routers are compartmented... This is where things get complicated. If the remote system is labeled "secret" then all systems that can connect must also be "secret", or support secret.
The easiest security violation would be to connect the network supporting the non-multi-level system to other non trusted systems. This is "trusting the network" for your secret data; which is why I would like to see all systems with multi-level security (and IPSec with data encryption on the host, and ....:).
The other part of your question is "find the right window to alter". The CMW would have "grey out" windows for all lower level open windows. This allows you to focus on the non-"grey out" windows which are active, and can be modified.
BTW, even the ability to relocate the lower level windows is removed - the information leak here is the ability for X applications to determine their coordinates on exposure events. Data from a higher level environment could be represented in screen coordinates.
One other area: What happens if you want to terminate the high security level processes and return the previous level?
Shouldn't be a problem. What needs to happen is: 1. all active windows must be terminated (those at the high level) 2. all X atoms that are at the high level must be purged (after all, Xdefaults added after switching may have secret data) 3. The high level clipbard must be disposed of too. 4. The security stack is dropped to the previous level. 5. The X server is informed to restore the "grey out" windows of the new "current level" windows, making them available for modification. Note: any windows that are lower than the current level remain "grey-out" an not modifiable. > > These are all probably trivially solved by some implementations, > but I'm just curious to how all this is handled smoothly?
It's not trivial - it just takes a lot of tracking, and very good software implementations. There have been no questions about what happens if a lower level application updates it's display - does it take place? is updating prevented? depends on the window manager I think.
This amount of X security support is not possible at the present time. Neither the X server, nor any window mangers have been validated for this and they haven't been programmed to support level changes. But then neither has Linux (yet... see RSBAC at http://www.rsbac.de/rsbac/).
> -linda > (who wonders at the complexity of all these interactions)
In some cases - this looks like a place that C++ object oriented programming could come into it's own. It does seem to handle data cleanup rather well. ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |