Re: Hypothetical design question

[Glenn and Mary Everhart <Everhart () gce com>]

Well, the OS can be in a position to have a pretty good idea
what is coming from a user and what isn't.

We've been poorly served by examples like "cp foo.bar mumble"
or "rm a.b,c.d" where the command comes from someone who has
(barring bugs) logged in.  Oftentimes we have large programs
which access resources all over a machine.

By assuming that these are operating with the authority of the
logged in person (all too often, a person with system privileges)
we are in the position of having to trust programs with everything
in the system, not a small part only. The system really should
limit rights to what can be touched for every subject identity,
with overrides that can be used ideally from a trusted path to
the subject (user) and possibly allowing explicitly named resources
to be altered if the subject is authorized. However, the presumption
should not be made that all programs running do so with the authority of
the person at the console (or logical equivalent), but that they
have, perhaps, a "guest alien of possibly hostile intent" level of
trust, absent evidence that a human agent wanted them to act. Command
line commands would on the whole work as before, because they do tend
to take explicit operands, though it should be rare that even one
with system rights has the right to execute "rm -rf /". People make
mistakes too easily.

A philosophy like this would tend to make it difficult for an intruder,
even who gains control of some program legitimately run by a human, to
do much with that control. It would mean computer systems are being much
more careful about who they assume the "subject" of a "subject performs
operation on object" security model is. That is the root cause of many
holes.

Now, obviously, if my machine trusts a few bytes of an introductory
packet to authenticate a user, the walls can be breached. But it gets
harder.

Until such things get implemented, even some simple old ideas might be
helpful; things like a subsystem that will let one convince a program that
it is running with system access, at a time settable, and yet which will
control its access and allow reporting of what resources the program tries
to use. To some extent such a tool is a reasonable adjunct to a careful OS
by giving anyone who receives an unknown program (be it compiled or a script)
a way to tempt it into mischief if it is so inclined. That is a much more
satisfying way to establish trust in it than thinking you know where it
came from.

Until we have OSs that treat actions as coming from unknown subjects
until proven otherwise, and protect against those deemed dangerous, we
will continue to have problems of exceeded authority, system cracks,
and so on. This is of course not the only thing needed to bring a
better controlled system to being, but it seems likely to be one of
the things needed.

Glenn Everhart

Nick Lothian wrote:

The problem with "restricting malicious things" is that the 
same action can
be veiwed as desirable or malicious, depending on intent.  
Intent is an

intangible.  Computing systems tend to deal poorly with intangibles.

If I type 'rm -fr /', my intention is to prepare a machine 
for a new OS
load, prior to a reformat.  If an intruder types 'rm -fr /', 
his intentions
are *likely* (can't say for sure without directly asking the 
intruder!) to

be somewhat more malicious.

The OS has no way of determining who the "real" user is and 
which intention

is desirable and which isn't.  If you try to enumerate a list of
"potentially malicious code" that shouldn't be run from 
Application X you'll
be at it for the rest of your life; a never-ending, 
never-winning battle.

:-(




Exactly. That is why I dreamed up the persistant codebase thing.

Nothing recieved from email should ever be able to execute rm -rf, nor
should it ever be able to send email itself, nor open sockets, etc - even if
it has been saved to disk and is being executed later.