Re: Cookie jar patch for Supexec/Super patch?

[Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>]

Konrad M Kokoszkiewicz <draco@mi.com.pl> writes:

|>> > > I originally proposed a system call that would read a cookie, set a cookie,
|>> > > destroy a cookie, and get a list of cookies - this call would also read the
|>> > > hz_200 variable, and a few others as if they were cookies.  The cookies were
|>> > 
|>> > That's good idea. :) Of course, we can add TWO calls, one for reading 
|>> > GEMDOS variables (various ones) and one for Cookie Jar management...
|>> 
|>> I still can't see the reason for this changes: MiNT is NOW TOS, and so 
|>> can't be made more secure than TOS. There are thousands of programs which 
|>> access the supervisor areas (Cookie, variables) and you can't hope they 
|>> will ever be recompiled with new MiNTlibs. If you make the changes the 
|>> programs won't run under new MiNT anymore? If yes, the new MiNT will be 
|>> useless.

|> Petr, this security discuss is so far only a discuss. Nobody has
|> introduced any security oriented function to the kernel so far. But
|> generally, in my honest opinion, such a fix is possible. Your "thousands
|> of programs" accessing GEMDOS variables in supervisor mode, are mostly
|> GEM applications. If (future) Super()/Supexec() would be root only,
|> these programs will still work if your run GEM as root.

|> As for Unix-like tools and applications (like these included into the
|> KGMD), they can be recompiled.

Don't forget the non-GEM programs that never heard about MiNT, or those
that don't have the sources available or are compiled with strange
compilers.  I'd guess that nearly all of them will want to access TOS
variables.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"