Re: Security stuff

[Charles Briscoe-Smith <cpb4@ukc.ac.uk>]

This debate is getting ugly.  I will try to summarise and correct a
misconception or two.  (But please bear in mind that it's about 18
months since I used MiNT seriously; I've switched almost entirely to
Linux now.  I may not be up-too-date.)

Konrad M.Kokoszkiewicz wrote:
>The point is that you can't run GEM remotely (via telnet). If you're able
>to run GEM, it mostly means, that you're root on the machine, and the root
>has no reason to hack own system.

Having root access (i.e. being able to override security on the
machine) is entirely independent of, and orthogonal to, the issue of
remote versus local access.  It may be that on -your- machine local
users are trusted and remote users are not, but this is not the case
for everyone.

In any case, the location of the user makes no difference to the OS.
Suppose that a user has logged in remotely, via telnet.  The shell he's
using is a normal MiNT user process, and can (attempt to) do anything
that any other normal MiNT user process can do.  A GEM program runs in
a normal MiNT user process too, and routinely calls functions in the
AES and VDI.

[ Note: I have no experience with GEM versions later than the one built
  into TOS 2.06, and have not tried any of the AES/VDI replacements.
  Hereafter, my comments refer to that old version of GEM, although I
  believe they are probably applicable to newer versions, too. ]

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.

Konrad M.Kokoszkiewicz wrote:
>I thought it was so simple, that most people could understand it. But I
>was apparently wrong; I can even say I am disappointed, because YOU,
>famous Julian Reschke, who wrote Atari Profibuch etc., seem to don't
>get the difference between a local user (who is supposedly root and
>can run GEM and GEM programs) and remote user (who can use only telnet).

The point is that remote users -can- run GEM programs.  The programs
will not work as intended (they will attempt to display their output on
the console, probably disrupting whatever is being done on the console
at the time) but they can still be -run-!

Julian Reschke wrote:
>Or maybe I'm right, wouldn't that be another possibility?
>
>Yes, I do understand the concept of remote shells and so on. If you are 
>intending to protect your system from people running a remote shell under 
>MiNT, then please explain how you want to prevent them from running a
>program which just does one AES or VDI call and that way gets access to 
>supervisor mode?

Konrad M.Kokoszkiewicz wrote:
>By keeping such software on another partition, where people working
>remotely have no access to :) 

Konrad, that's called "security by obscurity" and it does not work.  If
a user has access to a shell on your machine, you can't prevent him
from creating and running any arbitrary executable without severely
limiting the machine's usability.

For example, suppose the user has access to only -two- commands:
uudecode and chmod.  The hacker creates a program on his computer,
calling it "hack.prg", and uuencodes it.  He then telnets to your
computer, logs in and types

  % uudecode

He then sends the uuencoded executable down the telnet connection (this
is directly possible with the right telnet client, or you can
cut-and-paste).  This creates a copy of "hack.prg" on your computer.
Next, he types

  % chmod +x hack.prg
  % ./hack

He has now executed his code on your machine.  This executable may call
GEM functions, and so may breach security.  Of course, if the hacker
has access to the C compiler on your machine, this all becomes a lot
simpler and involves a good deal less messing around.

This is why GEM calls -must- be restricted to root only if you want
your system to be secure.

Julian Reschke wrote:
>If your answer is: no GEM anyway, then I must ask why you don't simply run 
>Linux....

Konrad M.Kokoszkiewicz wrote:
>I don't run Linux, because I am running MiNT and I don't need more
>operating systems on my disk. I do run MiNT, because I think it is
>functionally the same as Linux or any other Unix, plus it gives me
>possibility to run GEM and GEM software on the console.

If you use GEM programs on your machine, then Julian's comment above
does not refer to you.  Please re-read it and tell me if that is not
the case.

>       There is a
>system which can run either pico and Calamus at the same time, all the
>time being on line and available for remote users. This system is MiNT.

Then use MiNT.

If you want it to be secure, though, GEM calls must be restricted to
the superuser, and you must be the superuser to run GEM programs.

As I see it, if you want to use UNIX-style programs -only-, and have an
'030+FPU (or the money to upgrade), then Linux is probably the best
bet.  If you want to run both GEM and UNIX-style programs, use MiNT.

--Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94  B8 21 2D 01 DE 66 13 E2