[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Security stuff



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

this text is an example of a perfect logic, and I mostly agree with your
conclusions. There's only one thing I dislike in your and other's style of
thinking. Some of us seem to prefer a style which is called "reductio
ad absurdum" (reduction down to an absurd). If there's a proposition to
make MiNT *more* secure, it is laughed off because the proposed solution
won't make MiNT *perfectly* secure. Opposedly to pepole, who think that
incomplete security is worse than perfect security, I think that
*imperfect* security is better than *no* security. 

At this occasion I would like to remind, that the discuss began when I
posted a mail on it is possible to remove root process using ftpd. This
needs an immediate fix without any doubt, the rest may wait.

Regards

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)