Messages in this thread | | | Date | Wed, 8 Mar 2000 01:01:16 -0500 (EST) | From | "Albert D. Cahalan" <> | Subject | Re: Capabilities |
| |
Jesse Pollard writes: > 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. ... > 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 ... > 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.
This too looks like a "checkbox" implementation. It might be just a tad more useful than the Windows NT POSIX subsystem.
Doing this right would be something like:
1. each security level gets a private backing store 2. windows only see expose events within their own level 3. windows can be mixed on the screen 4. a single taskbar indicates security for the keyboard focus 5. window borders are colored; outside the active window is greyscale 6. windows are not allowed to jump under your mouse
> 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 ... > 2. By the principle of "least privilege" you would get the minimum > of your allowed levels.
This is poor. You should not log in at any one level. Window systems that operate in this manner are just a tiny bit better than single-level untrusted window systems. You'd get almost as much usefulness just running a separate X server on each virtual console.
>> 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).
Sadly it is difficult to do better than this. You'd have to propagate security data back up to the window manager via a trusted shell, trusted su (well, it ought to be...), and trusted xterm. Ugh. You'd most likely also want a trusted multi-level ssh.
>> 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.
It could fail only when background processes exist. Getting all the details right could be hard, but I think that solving these problems would greatly increase acceptance of multi-level systems.
This thread is starting to wander far from "linux-kernel" I think. I hope people find it interesting anyway.
- 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/
| |