Re: The Demise of Simple Assurance?

Previous message: jmjonesat_private: "The Demise of Simple Assurance?"
In reply to: jmjonesat_private: "The Demise of Simple Assurance?"
Next in thread: jmjonesat_private: "Re: The Demise of Simple Assurance?"
Reply: jmjonesat_private: "Re: The Demise of Simple Assurance?"
Reply: Crispin Cowan: "Re: The Demise of Simple Assurance?"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Valdis.Kletnieksat_private

On Tue, 31 Jul 2001 15:43:25 EDT, jmjonesat_private said:

> It is conceivable that a module COULD change fields in this structure 
> that would later circumvent in-kernel security checks, interfering with
> the in-kernel checks and, likewise, with the "simple assurance argument".

> Some Solutions:
> 
> Allow authoritative hooks, which are applicable if the "simple assurance" 
> argument drops below radar, imho. (In essence, abandon the "simple
> assurance argument" completely.)

Umm.. if a module could screw with the structure, it can screw with the
authoritative hooks.

If you've got a rogue module running inside the kernel, the game is All Over,
unless you have hardware support for "rings" or "address spaces" or the
like so a module can run in a 'semi-priviledged' state.  I believe Multics
allowed that, and IBM's MVS-class systems have some support for similar
concepts.

But if you've got a module loaded in a Linux kernel, and it's trying to
play games with your brain, you've got bigger problems.

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech