[Jonathon Tidswell (MS Research Fellow) <t-jont@microsoft.com> writes:]
>All resources need to be protected by their respective servers, a microkernel
>design does not want to include excess material in the kernel, but
>shifting the responsibility does not solve the problem it simply
>increases the number of
>places it needs to be addressed, and correspondingly the number of places
>it can be poorly addressed.
True, but much of the code is still shared (courtesy of libraries). It also
allows filesystems to omit code which makes no sense--for instance, the DOS
server has no per-user security or resource controls because the filesystem
itself does not understand the concept of multiple users.
>> > Non-disclosure is normally an issue of simple Trojan horses, covert
>> > channels (unintended information channels) and users incorrectly
>> > setting their permissions.
Covert channels are a black hole. There are too many possibilities for
modulation, and a useful general-purpose system does not result from
blocking them.
>> I think systems that block the flow of information from "classified"
>> to "unclassified" can be built on top of the current protection model.
Mandatory access control can not be built on top of the current system.
More kernel mechanism would have to be added to forbid connections between
different levels. MAC is only marginally justifiable, IMHO, because if you
can trick them into trying to give you the data, you can usually trick them
into giving it via covert channels (see above).
>I would like to describe a Trojan horse that currently seems possible.
>If I've slipped up please tell me so.
Nope. Well, maybe. Since any process can enable/disable any of its ID's, it
is entirely possible to disable all your "useful" abilities and forge
perhaps a very modest subset ID. Your "po" utility thus does NOT have to
inherit everything the user possesses.
The user-manipulable hierarchy of ID values makes this quite practical.
Assume I'm ID 1.2. I save all my mail and such under 1.2.1. Now I'm going
to run that "po" program of Jonathon's, so I forget 1.2.2, delete 1.2, and
run it. "po" tries to snatch my mail, but since it was saved under 1.2.1
with protection 0.0.7, he can neither read nor write it. Because he holds
1.2.2, he could forget 1.2.2.*, but never 1.2.1.*.
Lest I forget, your ID's are scanned at time of connection to a server.
When you manipulate your IDs, you must reconnect to your file servers,
otherwise your access will not be recalculated.
In practice, in a UNIX-ish world, your attack would be practical (assuming
you can convince users to run your command).
I've pondered a database of paths and a tabulation of "how much" to trust
programs under them. This might contribute to a solution, because you could
then have your shell automagically reduce abilities as it goes about running
the suspect code.
Andy
Received on Wed Dec 14 10:28:50 1994
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:11 PDT