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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:13 EST