Re: Security stuff

[Hartmut Keller <keller@goethe.informatik.uni-stuttgart.de>]

>>>>> Charles Briscoe-Smith <cpb4@ukc.ac.uk> writes:

> As I understand it, we cannot ensure that all AES and VDI functions are
> safe.  They run with enhanced privileges (in supervisor mode, I think)
> and they may do insecure things.  If a user without root access can
> call a GEM function, he may be able to gain root access, or otherwise
> disrupt the machine.

> Therefore, non-root users must not be allowed to call GEM functions.


Wait a minute. There's something I don't get. Why is GEM unsafe? What
do you mean with "we cannot ensure that all AES and VDI functions are
safe"? I think we must distinguish two problems.

1. Does a user get access to supervisor mode by calling a GEM/VDI/AES
   function? Or to any other vital system resource?

2. Does GEM/VDI/AES influence the system's behaviour in a bad way when
   called from somewhere else than the console?

Ok, here my thoughts to these points:

1. A GEM, VDI or AES call is in fact a trap-exception. This means that
execution *is* changed to supervisor mode and GEM *is* running in SV
mode. But who cares? Every function returns savely back to the caller
in user mode. It is only a problem if there is a way to register a
call back function in GEM which is called in SV mode. Then this
is an indirect way of gaining access to SV mode: register function,
trigger callback, there you are. Does GEM offer such a feature? Then
these register functions should be restricted.

2. I always thought GEM was written to be used for multiple
"workstations", at least this is what a call "OpenWorkstation" or
"OpenVirtualWorkstation" means to me: an additional user registers his
presence. So it should be multi-user safe in some way. It even might
be able to send Metafile-Data over some network to be displayed
somewhere else. (Ok, I may be totally wrong here, but that was always
the way I saw GEM).

But if this is *not* the case and GEM is only safe for one screen and
this is the console, then can't we just insert a check in the
appropriate trap handlers to verify if the calling user is sitting at
the console? And deny access to any function if not.


Ok, I may miss something totally obvious here, then please be patient
with me.


Hartmut


+-------------------------+-----------------------------------------------+
|  Hartmut Keller         |  Internet: keller@informatik.uni-stuttgart.de | 
|  Inst. fuer Informatik  +-----------------------------------------------+
|  Breitwiesenstr. 20-22  |  "If there's only one reason to live in this  |
|  70565 Stuttgart        |   world, I'll find it!"      (All About Eve)  |
+-------------------------+-----------------------------------------------+