Re: [MiNT] Security again

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

> > Apparently an experimental implementation was done of TraPatch for the
...
> > (no names here ;-) didn't like the possibility that programs hook into
> > GEMDOS traps/functions.
> 
> That's the main point, it's not a reasonable concept at all. Introducing
> this into the kernel break all security concepts. Any application(!)
> can override the complete system.

That obviously isn't true, since the kernel would have complete control over
what programs were allowed to use this feature. Just as certain programs
are allowed to use restricted operations of Ssystem(), which could also be
used to override the system.

I wouldn't expect a normal application to have those kinds of privileges.

> Kern is kern, application is application. An application must be outside
> the kernel.

Obviously. But I think our definitions of what a program is differs.
To me a program is not necessarily an application.

> > Now, I agree completely that it's generally a very bad idea to hook into
> > OS functions. Unfortunately, the design of our OS makes it necessary to do
> > so for many things that people consider useful. It's also a fact that most
> > people _have_ quite a few programs in their AUTO-folders that do just that.
> 
> No, I disagree. Any program that is executed after MiNT is an application
> and have to be run outside the kernel. Programs that are executed before
> MiNT are automatically part of the kern.

But in my opinion they really shouldn't be allowed to run before the kernel.
I would want all those programs to run later and then they would obviously
need a way to get their work done anyway.
It certainly can't hurt to give the kernel a bit of control over something
it previously couldn't do anything at all about.

Granted, the OS was bad to begin with, so we can't get all the way, no matter
what we do with MiNT. That doesn't mean that we should give up trying to
do something about the things we _can_ improve.

I wouldn't have the least bit of trouble with an implementation of a
TraPatch like protocol that only allowed it while MiNT was executing
programs from the AUTO-folder, for example.

> > So, outlawing TRAP-hooking is not really an option.
> 
> It's always an option. Tell me any useful reason to allow an application
> to override the system.

I'm not talking about applications here. I can't recall running into one
that hooked into any of the OS-call vectors.
They do, however, often put themselves in supervisor mode...

In my view, the kernel should have as complete control over the environment
as possible. That means that it should know about these things, if at all
possible. Right now it can't.

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