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:
>>> 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.
>> 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.
>> 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.
>> 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.
>>>> 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.
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.
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)
>>>> 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.
-
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:14 EST