Re: Experimental yet interesting securelevel patch :-)

James Mastros (root@jennifer-unix.dyn.ml.org)
Fri, 22 Aug 1997 08:24:56 -0400 (EDT)


On Fri, 22 Aug 1997, Kevin M. Bealer wrote:

> Chris Evans wrote:
> >
> >Hi,
> >
> >Attached is a patch relative to 2.1.48 which should actually enable
> >securelevel to do something useful!!
> >
> > [..]
> >2) Two of the options will break X when enabled, namely SECURE_PORTS (X
> >does iopl()) and SECURE_MEM (X mmap()'s /dev/kmem for linear
> >framebuffers). dosemu will suffer similarly, svgalib, etc.
> >[NOTE: In theory, a GGI patched kernel will run fine, as GGI removes
> >direct port hacking from userspace and puts it in the kernel where it
> >should be. Nice solution eh?? :-) ]
>
> Due to #2, a hacker who could not gain root access could still cause
> various applications (X, gs, etc.) to fail by bumping the securelevel
> himself. A solution might be to have a bit that prevents tampering
> with the bits that are "dangerous" in this way. You could shut down a
> print server that uses gs if svgalib is shut down, as (I think) gs
> needs to link with it.
>
> One thing I am confused about with securelevel - how does the machine
> get rebooted? If a hacker can get root access they can reboot, yes?
> Then the secure level is gone? (I know this isn't related to your
> modifications, per se.)
>
>

1) Gs needs to link with svgalib, perhaps, but svgalib wouldn't fail untill
it initalised. (So your fine unless you acatually use svgalib, I assume that
gs won't do this unless you specify to use svgalib.)

2) securelevel is -rw-r--r--, no? So you would have to gain root acc. to
screw with the computer this way. If you have root access, there are easyer
ways to screw things up. (Although putting all ones into securelevel before
you leave might be nice.)

3) Then set securelevel before you allow any access to the system. And
hope that the hacker dosn't edit your /etc/rc.d/* before they boot.

-=- James Mastros