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/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:22 EST