Jesse Pollard writes:
> 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:
>>>>>> [--snip--snip--snip]
>>>>>>>> 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 host B won't propagate back, then host C should not trust host B.
Host C is misconfigured.
> In a network, the number of possible combinations grows very fast.
You only have to consider direct interactions, giving O(n) combinations
instead of O(n*n) combinations. Commonly one interaction is a pty, and
the other interaction is a network socket with a well-defined protocol.
You can establish the credentials of the process on the other side of
one of these connections. Either you trust or you don't.
> Even if host B is trusted, host C may trust host B, but not at
> the high level.
No problem. Configure sshd on host C to limit the security level
that it is willing to propagate back to host B.
> host C may not trust host A at the high level, but host B does
> trust it there.
This is going beyond paranoid, and I think you have a "hole" even
without security level propagation across a distant login.
Spies just do this:
1. move secret data from C to B
2. move secret data from B to A
There, done. Secret data from C is now on A, even though C does not
trust A at that level.
>>>> 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 covert channel is one of many. You only need to ensure that
the bandwidth is documented and/or below 300 bits/second, depending
on what kind of security you intend to have. Cut the time stamp
resolution, add some random delays, and limit connections/second.
>> 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.
OK, so we implement the extended security packet.
One may also rely on the trusted software that inplements the
protocol. Remember that ssh and sshd are both trusted, and that
they can use an encryption algorithm that you trust to secure
all of your data. You can have a multi-level tunnel through
a single-level TCP/IP connection. You can even generate dummy
traffic to defeat traffic analysis.
>>>> 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.
Yes, but this is not really a problem.
If you somehow manage to make a trusted-script program, then it will
work as it should. (generating files with the right level)
If your "script" program is not trusted, then you can't change your
security level through it. This will most likely be the case, since
one would want to avoid trusting damn near everything.
>>> 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.
You should not trust buggy software. You get what you deserve
when you trust buggy software.
> Even if the script command were trusted, what happens to the
> log file....
I don't know, but trusted-script will take care of it. Maybe you'd
get a multi-level directory containing multiple files with the
same name, one for each level.
> 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).
This is all just more of the same. The problem is solved. You can
apply the solution to any example, no matter how complex you make it.
First of all, putting passwords in a file is already a major policy
violation that no system can prevent.
When the setuserlevel command happens, sshd will try to propagate
changes back across to the ssh. No problem, I already explained this.
Now ssh and/or the kernel will notice the redirection. Since it is
most likely not possible to propagate level changes across a normal
dumb pipe, ssh will report failure back to the sshd.
Well, that was easy. One could attempt to propagate across the dumb
pipes with proper kernel assistance for out-of-band security messaging.
This will certainly fail, because nobody sane would try to implement
a trusted awk. Not that you couldn't though...
>> 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.
The more you trust, the more you can do. Trust is risky.
There is a trade-off to be made here. What else is new? :-)
You make your choice about what you trust and you reap the
benefits or suffer the consequences.
-
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:15 EST