Re: [MiNT] Security again

[Johan Klockars <rand@cd.chalmers.se>]

> > Yes, but as I said, you wouldn't give this ability to just any program.
> > If you want, make it restricted to 'formerly before MiNT, AUTO-folder'
> > programs and you have exactly the same as right now, only with some degree
> > of kernel control and much better system call efficiency.
> 
> And in what way you decide if such a program have the right permissions?

Have a special flag, like the ones for memory mentioned, only allow it
for programs run as 'root' (well, IIRC that doesn't help much if you use an
AES, but...), or only allow it for 'AUTO-folder' programs.
Or any combination thereof.

> And it don't solve the problem itself. It only workaround some
> sideeffects.

I don't think I follow you there.

> > cases where it _currently_ would step into supervisor mode or otherwise
> > change vectors on its own (Setexec()?).
> 
> Setexc() is a system call. So MiNT have control over it ...

So would the TraPatch call be, with the same control possible.

My point was that you can't prevent current applications from using their
own vectors (or they will stop working), so the applications can get into
supervisor mode. End of story.
If you would stop an application from doing things like this, you could
just as easily stop it from using the TraPatch call, so there would be
no difference whatsoever.

> > _Some_ system control is surely better than _no_ control?
> 
> You win *eventual* _some_ control but loose any security mechanism and
> loose a lot more stability as it's good.

I don't see how you can defend the current mechanism with absolutely _no_
control. Nothing can possibly be a more severe threat to stability than
completely unchecked vector bending, which is going on now.

How could stability possibly be adversely affected?

> > No. As I outlined the TraPatch-like functionality you wouldn't loose
> > _anything_ from what we have now. You would only gain.
> 
> Sorry, I can't agree.

If you could only name one thing that you would loose, it would be easier
to understand your reasoning.

How can this

   move.l  #usage,-(a7)
   move.l  #vector_number,-(a7)
   move.l  #routine,-(a7)
   move.w  #TraPatch,-(a7)    ; MiNT TraPatch call
   trap    #1
   add.w   #14,a7

in any way be worse than this

   <go into supervisor mode>     ; MiNT isn't running yet
   move.l  vector*4,old_vector
   move.l  #routine,vector*4
   <leave supervisor mode>

?

> > Granted, this isn't how TraPatch itself works, but then that wasn't a
> > MiNT kernel call.
> > I have no idea how the proposed version for MiNT looked, but that isn't
> > what I'm talking about here, anyway.
> 
> You can look for the rejected trapatch version in the rejected folder.

That isn't relevant, since I'm not talking about that implementation.
As far as I know it could have put a little rodent into your machine, but
that doesn't mean that what I'm proposing is a bad idea.

Perhaps you haven't read what I've written here?

> And, it was a system call.

Definitions again.
'MiNT kernel' call = system call.

TraPatch wasn't that, it was a TSR that implemented some functionality by
itself. It certainly had nothing to do with MiNT (although I gues it could be
used together with it).

> > Currently we don't have any control over what you call parts of the kernel
> > (that is, the AUTO-folder stuff that runs before MiNT), which is one of the
> > things I'd like to do something about. The other is system call efficiency.
> 
> No, you can't override the system at the moment. If MiNT run all
> GEMDOS/BIOS/XBIOS functions are under control of MiNT.

Since MiNT isn't running when those program are started, it doesn't have
any kind of control over what they do. If you're talking about MiNT ending
up first in the chains afterwards, that can be changed by anything that
goes into supervisor mode, which the original routines will of course be in
if MiNT ever decides to call them. I know of at least one such program that
moves itself to the top of a TRAP-chain later on.

In any case, the control I've been talking about has been in relation to
the TraPatch-like functionality, which would make MiNT aware of what things
were out there and who linked into what.
Sure, this won't improve system security much, but it certainly doesn't
make it any worse. The main point about this is to get rid of the
TRAP-chains and speed up system calls, the rest is just a relatively minor
side benefit of having MiNT take care of this.
(Well, having a 'standardized' API is perhaps not so minor.)

> Your idea is to (explicitly) give up that control.

I'm not giving up _any_ control.

Could you please explain what control is missing here

  Load and run MiNT.
  MiNT loads and runs various AUTO-folder programs that ask MiNT to be
    included in various TRAP-chains.
    (That is, MiNT can place them anywhere it likes in these chains.)
  Further programs can't link into vectors unless MiNT specifically allows it.
  Run init/desktop/whatever.

compared to this

  Load and run various AUTO-folder programs that can do as they please.
  Load and run MiNT.
  Further programs can't link into vectors unless MiNT specifically allows it.
  Run init/desktop/whatever.


I _really_ have a hard time understanding why you think the latter is in
any way preferable.
(Well, except that it wouldn't add anything to the size of the kernel, but
 you're not among the people who're worried about that. ;-)
  
-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johan@rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)