Hi, this is my other identity....
On Wed, 08 Mar 2000, Albert D. Cahalan wrote:
>Jesse Pollard writes:
>> 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.
>
>There isn't any leak.
>
>I suppose the X server and window manager actually do have current
>levels from a kernel viewpoint, but they also have capability bits
>that let them freely change level. They are Trusted.
>
>To the user, the window manager should appear to not have any
>particular level at all. This may well be implemented by changing
>level, just as a userspace NFS server appears to operate without
>any particular UID.
I see where I missed your point. You are right - the window manager doesn't
really have a single level, and neither does the X server, just one active level
at a time. It does provide the user a context - just as the concept of current
working directory does to processes and user shell interface.
>>>>>> 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.
>
>What is not part of CMW?
>
>If you mean "feature is actually well thought out and usable" then
>of course I agree, and I don't care. Nobody but a PHB would want
>to install a poorly designed system that just happens to barely
>meet the minimum requirements.
>
>If you mean something about checkboxes, you should read the above
>text a second time knowing that the "checkbox" is not something
>you see on your computer screen. The checkbox is mental; it refers
>to the way someone might compare systems for purchase. Like this:
>[x] has CMW
>[x] meets POSIX
>[ ] looks like Win95
>[x] fits the budget
>[ ] easy to use
>[ ] tech support has clearance
>[x] our admin is already trained
oops sorry - I misinterpreted that one too. I thought you were talking about
a dialog check box...
>>>>> 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.
>
>No kidding, and you don't need a stack for that.
Sure don't - it just provides a tracking device to allow the switch back. I
believe they thought it better than having a random assortment of levels and
try to switch randomly among them. Doing that might make the memory management
of the X server and window manager unmanageable.
>
>> 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.
>
>OK, so only the visible representation can be spoofed. If so, then
>the visible representation isn't useful --> it can be eliminated.
It was only provided as a piece of context information. Other than that it
didn't supply anything I know of.
>
>>>>> 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.
>
>Who said anything about it being OK to mix data? Being "secure"
>in this case means not confusing the user with spoofed windows.
>If you could rely on the user to check what security level will
>receive keyboard input, you'd only need a single Trusted Pixel.
>
>>> 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.
>
>No, that is just an implementation problem. Elimination of this
>problem DOES NOT imply that data from separate levels can be
>freely mixed.
>
>>>>>>> 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.
>
>What "target software" do you refer to?
How about a quickie connection diagram:
CMW ----> host A ----> host B ---> host C
The system "host c" is a MLS host (say trusted HPUX), host b is a fixed defined
level host (IRIX???), host A is a trusted Solaris. If the connection on host
c attempts to raise its' security level, then that has to propagate to host B,
then to host A ...oops host B didn't know it was supposed to pass that back to
host A.... security violation has now occured. If the switch to high level on
C was permitted, then high level data leaks onto B and then back to A and the
CMW. In a network, the number of possible combinations grows very fast. Even
if host B is trusted, host C may trust host B, but not at the high level. OR
host C may not trust host A at the high level, but host B does trust it there.
Trust is not usually transitive. That is an organizational type policy
definition that can't be enforced by software, except where explicitly designed
into all pieces of the system (kernel included).
>If something is unknown or unsupported, you fail. You can't
>expect two totally different systems to fully trust each other.
>
>This does not prevent operation between cooperating hosts.
>
>>> 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.
>
>Sure it does.
CISCO routers don't permit it, that violates the Bell-LaPadula security
model which is part (most?) of the MLS implementations. Back propagation
also allows a covert channel of information - it releases the time a channel
changed security level (or requested a change...).
>
>The remote tty level change causes the remote ssh server to query
>back, through a trusted network, to the trusted ssh client.
>The local ssh client can, assuming the process group checks out,
>deal with the local pty and through that change request influence
>the local xterm. Should the xterm refuse, the initial tty level
>change on the remote pty (still blocked) will fail.
>
>The TCP/IP connection could be made to change level, or one could
>simply rely on ssh and sshd being Trusted. There won't be any leaks
>because you trust ssh and sshd to manage the security data correctly.
>Evil clients would not have access to the right keys, so they fail.
>Evil hosts don't get put on your network I hope, and in any case the
>IP-layer encryption should solve that problem.
The IP layer encryption only guarantees integrity and confidentiality of
the data during transport. It does not support MLS anywhere, or even user
identity - that information is encapsulated in the extended security packet,
which is not currently implemented. A version of it is supported in the CIPSO
(commercial IP security option) of some systems and routers.
>
>>> 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.
>
>If "script" is not trusted, it will be unable to cooperate
>with ssh to change the pty security level. This will cause
>ssh to return an error code to the remote system.
Absolutly - that is the source of the problem - there is too much software
in too many combinations to be able to validate all of them.
>>>>>>> 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.
>
>No problem, because "su" will know about the failure.
>
>> 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.
>
>Validation is simple. Every bit of software along the link is
>required to perform an acknowledgment which can only be done
>by trusted software.
That isn't validation - that is making an assumption. There are too
many software packages with too many buffer overflows and just plain
bugs for that to be done. Even if the script command were trusted, what
happens to the log file.... What if it were a redirected stdin? or a
redirected stdout.. something like:
progA <sample.input.commands | ssh trusted.host | awk {...}>output
progA may select specific commands to be passed to ssh, the return data from
ssh is sent to awk for data extraction/reformatting with the result redirected
to a log file. If the command to do a "setuserlevel" raises the security level
above the pipe or the output files what happens. What about the stderr from
both ssh and awk, what about possible shared memory segments (awk is replaced
by something else).
>
>If you put "something the user wrote" in your TCB with all the
>capability bits it could want, you get what you deserve.
>
To be able to define all system software as trusted is not something that can
be done. There are too many millions of lines of code with too many locations
of error.
It is much more usefull to be able to use the software, but protect the
information. Since the software cannot be validated the situation devolves into
the case of single level connection only.
-- ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@cats-chateau.netAny 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 : Wed Mar 15 2000 - 21:00:14 EST