Re: Security stuff

["Konrad M.Kokoszkiewicz" <draco@mi.com.pl>]

> > 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.

Thanks for reasonable opinion :)

Konrad M.Kokoszkiewicz

mail:draco@nidus.mi.com.pl
http://www.orient.uw.edu.pl/~conradus/
 IRC:[Draco]

*** Ea natura multitudinis est,
*** aut servit humiliter, aut superbe dominatur.
*************************************************
*** U pospolstwa normalne jest, ze albo sluzy ono
*** unizenie, albo bezczelnie sie panoszy.
                                           (Liv. XXIV, 25)