Re: Domain X

[ekl@sdf.lonestar.org (Evan K. Langlois)]

I tried a normal reply, but this Unix system is running on a i386.  I kept
getting a stupid core dump!

========================================================================
 In my eyes, the story is yet more simple: Since DOM_X programs are per
definition not allowed to use BIOS/XBIOS/AES/VDI, just make these vektors
point to a kill routine. Checks must only be done if a programs wants to
switch back to != DOM_X. Once program is running under an old domain, trap
vektors are inherited by all childs until it switches to DOM_X, in which
case they're forced back to the kill routine.
========================================================================

No, I meant for MiNT domain programs!!  Only the local user should be
allowed to use AES/VDI/XBIOS calls.  Only root should be allowed to make
XBIOS/BIOS calls.  This won't affect the MultiTOS users or TOS domain
programs.  For DOM_X you either point to the kill routine or point to the
same protection routine as MiNT domain programs and add a check for DOM_X.
Or you could just totally give up on all MiNT domain protection, and save
protection to the DOM_X.  This would be easiest I guess, but the original
intent was to add some protection to MiNT domain too.

========================================================================
 This should makes the checks both easier and shorter. :-)
========================================================================

Yeah, I agree.  I guess things would be easiest, and adequate, if we
forget changing MiNT domain and just protect DOM_X.

========================================================================
 Ahhh. I've initially thought you wanted to make GEM secure. What remains, is
the problem that once I want to give a user the right to start GEM, I
therefore must grant him the right to switch back to DOM_MINT, and therefore
must *really* trust him.
========================================================================

GEM only runs on the local console.  If your going to give a user access to
run GEM, you have to let him sit at your computer!  That is the least
protected you can get as he could hold CNTRL-ALT-SHIFT to boot from 
floppy.  Load a hard disk driver from floppy, and then modify your MINT.CNF
file since it resides on a FAT partition which can be accessed without MiNT.
Then he points INIT= to GEM instead of an init program and he gets root
access through GEM.  Or he points INIT= to BASH and gets root access.  Anyone
at your computer can get super-user access very easily.  GEM only runs
locally.  This was why I originally wanted to make AES/VDI calls in a
MiNT domain program restricted to people at the local console, and simply
gone from DOM_X.

========================================================================
 Yet worse is that GEM/ROM doesn't work very well with memory protection and
thus I would have to switch this off when wanting to allow GEM access, which
is obviously a bad idea, since you can't do *that* per-process. That's the
point where I was thinking buying MultiTOS would be the only solution.
========================================================================

Yes, for memory protection, your only choice is to run MultiTOS, or no GEM.
There is no way around that!

========================================================================
 For me, it's easy: No GEM allowed at all. Others may disagree... :-)
========================================================================

Well, I'd like to use MultiTOS (if they ever release the non-polling one)
as the INIT= application, but have "init" loaded in the background and
running in DOM_X for remote users.  This is just as secure as no GEM and
allows me to run GEM programs.

There is another alternative than killing the program.  Point the trap
into a GEM emulator that makes X Windows calls!  Run GEM programs over a
network!  Imagine connecting an X terminal to a TT and having the X terminal
run Pagestream!   Impossible?   No .. but I don't think its likely to happen
anytime soon!!!

~.