Re: [RFC] LSM changes for 2.5.38

From: Valdis.Kletnieks@vt.edu
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-security-module@wirex.com
Subject: Re: [RFC] LSM changes for 2.5.38
Date: Wed, 02 Oct 2002 13:55:14 -0400	[thread overview]
Message-ID: <200210021755.g92HtGLw010852@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Tue, 01 Oct 2002 17:55:00 BST." <20021001175500.A26635@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]

On Tue, 01 Oct 2002 17:55:00 BST, Christoph Hellwig said:

> For gods sake, what interface do you want to /bin/mv?  network device don't have
> associated special files in Linux (or BSD).  I'm talking about SIOCSIFNAME.

Well, I figured that you must have meant something else, since ioctl() is
hooked, so an attacker couldn't use THAT method if the security module didn't
want him to.

Of course, that means we probably should pull that ioctl() hook too, since
obviously there's ways to bypass it.  And at that point, we may as well
pull the OTHER hooks too.  Hmm..  I'm starting to see a pattern here. ;)

So we shouldn't deploy a check on module parameters to prevent renaming
an interface, and we shouldn't bother having OTHER checks to stop it
because they could always load a module and bypass it - if you feel THAT
strongly that the whole concept of a security framework is that pointless,
you're free not to use it. ;)

> How does the lsm author know what the option x=y means for my module?  In my

Umm.. the same way that *I* noticed that 'eth=0' has a security implication.

It seems to me that you're arguing both sides here - first you say that
a full code audit is needed so you know 'WTF is going on', and then you're
saying that it's impossible to know.

Either that, or you're saying "yes you can do a code audit, but having identified
module parameters that are *KNOWN* to be a problem, you're not allowed to stop
them".

> From my reading of the LSM lists a hgook usually got added because author A
> of the unaudited module B though that it might help him in imlpementing what
> he and only he thinks his module should do if it worked properly.

OK - so to summarize:  You're saying that somebody conceives of a reasonable
security model, finds a set of 10 or 15 hooks that implement 95% of what
he needs, but there's a code path that a hook doesn't catch that lets a user
subvert the model - and then it's a *BAD THING* that the kernel be modified
to *actually solve a problem*?

Somehow, this goes against the whole spirit of the Linux kernel - I wonder
what miniscule percent of the current kernel wasn't done to solve a problem...
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]