Re: 'lock' modules?

From: James Sutherland (jas88@cam.ac.uk)
Date: Wed Jun 07 2000 - 15:03:56 EST


On Wed, 7 Jun 2000, Jesse Pollard wrote:
> James Sutherland <jas88@cam.ac.uk>:
(snip)
> >
> > 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.

That's close to the sort of thing I had in mind; if the kernel can be
configured so this attack requires multiple reboots and console access, we
can consider the system relatively secure from it :)

A global security level concept would be useful, IMHO; something like a
"secure console" command as the tail end of the init scripts would
probably fit the bill?

James.

-
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:30 EST