lkml.org 
[lkml]   [2000]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Capabilities
acahalan@cs.uml.edu  Wed Mar  8 00:01:18 2000:
> 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.

Not sure about "checkbox" thing, the user brings up a window manager
dialog to request a new level.

> 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

The "task bar" wasn't a list of tasks, but a stack of security levels.
the stack was nothing but informational, and could not be covered up.
(I suspect that was to prevent spoofing...)

> 5. window borders are colored; outside the active window is greyscale

not quite. All windows not in the "current security level" are greyscale...

> 6. windows are not allowed to jump under your mouse

Items 1,2,3 and 6 are all controled by the X server. Items 4 and 5 were
controled by the window manager.

> > 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.

It is the principle of least privelege. If the system is not authorized to
recieve secret data, then you will not be able to set yourself to that level.
If the user does not contain sufficient clearance for a given system, then
that system must not allow a login, even if the user is authorized elsewhere.

> >> 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.

Sorry - can't propagate backward. Even via ssh. There is no way for the
remote system to be capable of validating the transition. There just isn't
enough information available (I think it is an unsolvable problem too.).

>
> >> 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.

NOPE. it must fail always - consider Xterm at secret - su to unclassified
(this is invalid because...) cat >copy_of_secret_data; and now paste from
a different secret window into this Xterm - data is passed to su -> cat ->
copy_of_secret_data. This is the violation being blocked.
>
> This thread is starting to wander far from "linux-kernel" I think.
> I hope people find it interesting anyway.

I see it as background information for when X + Kernel mods begin to support
MAC. What has actually occured is a superficial design for a CMW version
of Linux. Wether this is good or not is opinion.
-------------------------------------------------------------------------
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.056 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site