So, 1) the intruder at this point has no access, and 2) can therefore not
introduce a 'butchered' insmod.
To recap, this is NOT an attempt to restrict an intruder (no shit, root can
do whatever he likes) just to give a friendly "are you _really_ sure you
know what you are doing?" to the legitimate owner of the machine, lest he
install a trojan or other nasty.
rOn
> -----Original Message-----
> From: Keith Owens [mailto:kaos@ocs.com.au]
> Sent: Wednesday, June 07, 2000 1:31 AM
> To: ronbarry@es.com
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: 'sign' modules? was: RE: 'lock' modules?
>
>
> On Wed, 7 Jun 2000 01:04:12 -0600 ,
> ronbarry@es.com wrote:
> >Anyway, what if we were to institute a system where a kernel
> module could be
> >digitally signed by assorted authorities as 'blessed?'
>
> Sigh. Why do people keep bring up this topic without reading the
> archives first? This has been discussed and rejected before but one
> more time ....
>
> Module loading is handled by user space utilities, not the kernel. To
> bypass signed modules a hacker can use their own user space code,
> either a butchered version of insmod or they just invoke the module
> syscalls directly from their own programs.
>
> Once more with feeling - "root can do anything that root is allowed to
> do". First design a mechanism to distinguish between a good and a bad
> root user, when you have working code send it to the list.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/