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 14:18:31 2000:
> Jesse Pollard writes:
> > acahalan@cs.uml.edu Wed Mar 8 00:01:18 2000:
> >> Jesse Pollard writes:
> >>> Linda Walsh <law@sgi.com>:
>
> >>> Sun also has a varient with X windows that is a "CMW" or
> >>> Compartmented Mode Workstation. This contains the following
> >>> security related software:
> ...
> >>> 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
>
> Right here I see a problem. You aren't really multi-level if you
> have the notion of a "current" security level. You only have the
> ability to switch between levels, and Sun is even a bit worse:

Sorry - your idea of multi-level is not multi-level. Information at a
high sensitivity level is not permitted to leak to lower levels. Period.

>
> >>> 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.
>
> What I mean by "checkbox" is that some manager has a checklist
> of OS features that they are supposed to get. Trusted Solaris
> gets a checkmark for supporting CMW operation, even though it
> doesn't work in a sane manner -- just like Windows NT gets a
> checkmark for supporting POSIX. The checkmark doesn't mean that
> the feature is actually well thought out and usable.

That is not part of CMW.

> >> 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...)
>
> The stack idea needs to be eliminated. It isn't even enough to
> prevent spoofing, since I could draw a fake stack. Heh... the
> stack almost makes spoofing EASY. In any case, the stack is
> a useless waste of space that makes GUI operation difficult.

It is valid in the context of a proper CMW. Information at a high sensitivity
level is not allowed to leak to a lower sensitivity level. BTW the stack
cannot be spoofed - the real stack is stored inside the trusted window manager.
The representation is only a visible reference. The visible reference does
not provide any security leaks at all.

> >> 5. window borders are colored; outside the active window is greyscale
> >
> > not quite. All windows not in the "current security level" are greyscale...
>
> Both methods are secure. They are in fact redundant with the taskbar.
> This can be a site-specific option, at least until it is determined
> that one method is less confusing than the other.

Actually the statement is about preventing high security level information from
being transfered to a low security level. The "grey out"/grayscale is just
a technique to be able to identify what may be modified at the current
security level. There is no mixing of "secret" data with "unclassified"
data. It is NOT permitted.

> >> 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"
> >> ...
> >>> 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.
>
> Yes, of course. What I meant above is that a user authorized for
> levels 2..6 on a system with 4..8 should log in at 4..6, not just
> the single level 4. (but one may choose fewer levels than allowed)
> You could have a "Start" button whose root menu offers a choice
> of security level, so that all levels are ready to use.

Sort of valid - but not necessary, it is equivalent. There can only be
one active security level though.

> >>>> 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.).
>
> No, this can be done correctly. It is just difficult.

NOT POSSIBLE. The remote system cannot know all possible target software.
The remote system cannot support all trust configurations.

> You can do the whole Trusted Network thing, with Trusted Routers
> and MAC data in your IP packets. Maybe VLANs would help. You can
> identify a Trusted Host by shared secret or huge public keys.
> With dummy traffic to stop covert channels, you could even do a
> Trusted VPN over the public Internet.
>
> The above gets you two Trusted systems talking to each other.
> You now need a way to deal with the tty. Well, that has a
> security level associated with it. You use a Trusted multi-level
> ssh client and server that understand how to manage the pty and
> tag traffic going across the link.

NONE of the above allows back propagation. They could not validate it.
It DOES allow a CMW to select a level, and then use that level to talk
to another system at the same level. It does NOT allow back propagation
though. It only allows you to use the level of the initial connection.

> The only thing left is dealing with the xterm. There are two ways
> to handle this I think, both of which require a multi-level xterm.
> Method one changes the pty level. Method two uses a separate pty for
> each level -- I suppose /dev/pts would be a multi-level directory.
>
> (and of course the xterm, knowing about X, can tell the X server
> to adjust the security level of the window)

NOPE again. If the Xterm is running a "script" command which is running
the ssh - sorry - no can do. The program running (script in this case)
does not have to be MLS aware. That is why the propagation path is impossible
for the remote system to track.

> >>>> 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
>
> No problem with Trusted Xterm!
>
> Xterm must change level in response to the new pty level.
> Going from high level to low level clears the scroll back,
> unless you want to get into individually tagged characters.

Xterm may not even be told about the change. See above. There are just
too many points of security vulnerability to be able to audit. The
ssh may be run under "expect", or something the user wrote, or it may
be the endpoint of a pipe. It just is not possible to validate the entire
path. I used to think so, but I found out that it wasn't. All software in
the link must be validated. Since it (some of it will be written
by users...) just cannot be validated therefore it is denied.
-------------------------------------------------------------------------
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.074 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site