James Sutherland <jas88@cam.ac.uk>:
> On Wed, 7 Jun 2000, John Alvord wrote:
> > On Wed, 7 Jun 2000, James Sutherland wrote:
> > > On Wed, 7 Jun 2000, Keith Owens wrote:
> > > > On Tue, 6 Jun 2000 21:57:19 -0400 (EDT),
> > > > buddy@foobar.resnet.gatech.edu wrote:
> > > > >I was wondering if anyone has considered modifying the linux kernel such
> > > > >that the modules may be 'locked'.
> > > >
> > > > Repeatedly. And the answer is always the same - "how can you tell the
> > > > difference between a good and a bad root user?". root can build,
> > > > change, load and unload modules, whether on this session or on the next
> > > > reboot. There is no way to distinguish between an authorised root user
> > > > and an "unauthorised" root user, a root by any other name has the same
> > > > power.
> > >
> > > True. Having said that, there may be some use in having a "lock system
> > > down" facility: after executing some command, it is no longer possible to
> > > [un]load modules. Alternatively, you could also make /lib/modules/`uname
> > > -r` immutable, and then just restrict module loading to subdirectories of
> > > that?
> > >
> > > There was one Linux breakin, IIRC, where the attackers used a kernel
> > > module to disguise their presence. If it had been impossible to load this
> > > kernel module in the first place, life would have been a bit harder for
> > > them...
> >
> > Would it help to build a system without module support?
>
> This would have blocked that aspect of the attack, yes - with hindsight.
> However, this isn't always possible; some features, IIRC, are only
> available as modules (PPP/SLIP components?)
>
> A better option, IMO, would be a facility to lock the machine down and
> block kernel load/unload after the machine has booted. Or, better still,
> some way of preventing any changes to /lib/modules/`uname -r`, then
> restrict module loading to that directory only.
That facility exists, just not in Linux yet - Multi-Level Security provides
that kind of control. During boot (at least up to the beginning of multi-user
mode) the system level would be low, allowing updates to modules/configuration
parameters. Once the security level is raised to multi-user, then the low
level files (ie modules/configuration parameters) become inaccessable UNLESS
the user logging in is permitted access to the low level (usually there are
no users at this level, except in single user mode).
The current Cray UNICOS implements three levels: syslow -- configuration
files, privileged executables (setuid root and security aware/privelged with
capability permissions), 0 -- used for interactive, multi-user/batch, and
syshigh -- basically just the private password data (shadow file).
This prevents any modifications to the trusted base/configuration.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:29 EST