Re: MiNT security problem?

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

> At present anyone can freeze the system for as long as they wish by simply
> entering supervisor mode. If they want to unfreeze it again they can do
> that too, and while it is frozen they can still use the machine (in a
> limited way).
> 
> How can this problem be avoided? It wouldn't be possible to simply disable
> supervisor mode for user programs since much software needs to be able to
> access system variables etc that are not accessible in user mode.
> 
> All I can think of is to impose some kind of limit on the length of time
> spent in supervisor mode, but this seems like a kludge which would be
> problematic in many cases.
> 
> Or am I missing something and this is in fact not a problem at all?

No, it is a problem and it was already discussed here some months ago
(when you were apparently off the list for a while). The result was:

1) Super() and Supexec() can't be blocked for now, because MiNT Libs use
   them. So, before these functions will be protected, new libs are
   needed and a complete new system distribution should be prepared.

2) All XBIOS functions (besides of Supexec) can and should be protected.

3) Some (or all?) BIOS functions should be protected too

4) kernel 1.14.5 has been released, where:

- Rwabs() is protected agains user access
- Dwritelabel() is protected too
- both functions depend on a new MINT.CNF keyword, SECURITY=YES|NO. If
  set to NO, all this stuff works traditionally, otherwise users have no
  Rwabs() and Dwritelabel() access.

No bug reports related to these changes have been mailed so far. Actually,
the next beta kernel from 1.14.x series will have the SECURITY keyword
removed and SECURELEVEL (0, 1 or 2) will be introduced instead. Levels
are:

0 - no protection
1 - all critical functions are protected except Super() and Supexec()
2 - all critical functions are protected

Besides, new MiNT kernel will support an additional GEMDOS function
(opcode $0154) called Ssystem(). This function is intended to allow user
processes (being exact: statically linked libs) to access Cookie Jar
pointer and one or two other necessary GEMDOS variables. Besides, the
Ssystem() provides some other additional system information - like kernel
identifier, full version number (including patchlevel number and beta) and
so on. The source code for Ssystem() has been already prepared by Jerry
Geiger and (sorry, not much time to do it) it is waiting to be linked with
the new kernel and carefully tested.

Konrad M.Kokoszkiewicz
mail:draco@mi.com.pl
http://www.orient.uw.edu.pl/~conradus

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