RE: [MiNT] Was: /proc, will be: /sys

["Konrad M. Kokoszkiewicz" <draco@obta.uw.edu.pl>]

> > Yes, nobody will setup a 'secure' setup on a MiNT box, but this is not
> > a reason to not have improved security - this is a *consequence* of the
> > fact that MiNT is insecure. So you're generally right, but the problem you
> 
> I'd rather say it's a consequense of the fact that MiNT is a poor choice for
> this - mostly because it doesn't run on powerful hardware and Linux, FreeBSD
> etc. does.

That only means you'll probably never see a MiNT box running Altavista.
This is however not a reason to refuse to make the resource protection
more hermetic, if it is already there. And actually, the thing "make Jar
private, put TSRs in super memory" was more intended for improving
stability than for making the system hackerproof.
 
> > I ask myself, what is this is all for? Obviously, such a piece of code
> > prevents an user with euid > 0 from achieving the same privileges as the
> > user with euid = 0 (root). There are privilege levels implemented, groups
> 
> You didn't get my point... Memory-protection and multiuser-features are very
> useful, because they prevent insane processes and ignorant users (or drunk
> owners...) to f**k up the system by accident, while some other
> security-features only serves to protect the system from evil hackers. When
> the latter conflicts with usability I'd say that usability should win.

Yes it should. But if there is such a conflict, the user (the superuser
actually, who is able to configure the OS) should have a choice between
being more (for example) secure or more (for example) compatible. This is
an expansion, not limitation.
 
> Let's take a look at the current situation, where read-access to /proc is
> restricted to your own processes. I'm writing a small application that
> displays a memory-fragmentation-map for individual processes, which I intend
> to use while developing applications.

But this relies on the internal realization of the memory management in
MiNT, which is a) not documented, b) not guaranteed to be kept the same
forever. So you're developing a program that is a hack :-), which may be
okay, but not okay is that MiNT could probably be forced in the future to
be compatible with your program (which in fact uses illegal programming
techniques). As far as I know, most of the proc structure is not
officially documented and usage of these undocumented fields by
application software is illegal.

> Now I have to run as root to be able
> to use this efficiently, something I usually never does. And running as
> root is risky if something goes totally wrong (like having the recursive
> filecopy in my NewbieMiNT-installer go mad).

Speaking of what, do you want to take a look at a little hypertext doc I
wrote for newbies? Maybe you'll find it useful for the newbie package.
 
> > At the other hand, the "multiuser support" and such code as shown above,
> > can be still easily worked around with few perfectly legal system calls,
> > so that any user can become root after a fraction of a second. So we not
> 
> And is this a problem?? I can't see why, unless some idiot decides to write
> a worm for MiNT... And currently I don't know any idiot with both an Atari
> and programming-knowledge... (TIFKAS can't code, can he?)

This is a problem, because it is (as I wrote before) illogical. I mean: 
one big security hole, that in fact allows to grant root privileges to
anyone, renders all other security and resource protection code not making
any sense, so leaving one such hole we know about, we can as well throw
the rest of the security code out of the kernel effectively reducing
ourselves to MagiC level of system support at this point. 
 
> > This results in "averagely secure" OS, so that anyone who actually know a
> > programming language and read the Atari documentation with some
> > understanding - may hack the root account in a minute.
> 
> Has this ever happened? This requires that this hacker has either physical
> access to a MiNT-box, or an account on some networked box.

Ehm, ask Janez :-) Well, I hacked his computer testing this stuff. And a
day before I hacked my Falcon similar way. Of course, my intention was
actually to fix MiNT so that it wouldn't be possible in the future (I
think I succeeded), but at the other hand, if I was able to do it,
everyone is able to do it.
 
> If these features can be implemented so they're not effective with
> SECURELEVEL=0, *and* they don't suck resources, I'm all for it. But not
> otherwise.

Finally we have a point where we agree. :-)

Gtx,

--
Konrad M.Kokoszkiewicz
|mail: draco@atari.org                  |  Atari Falcon030 user   |
|http://www.obta.uw.edu.pl/~draco/      | Moderator gregis LATINE |
|http://draco.atari.org                 |       (loquentium)      |

** 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.