[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)