Re: [RFC] LSM changes for 2.5.38

[Christoph Hellwig <hch@infradead.org>]

On Wed, Oct 02, 2002 at 01:55:14PM -0400, Valdis.Kletnieks@vt.edu wrote:
> 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.

Just that no 'security' module implements a special handler for it. E.g. in
selinux it ends up in

		/* default case assumes that the command will go
   		 * to the file's ioctl() function.
      		 */
      		default:
      			error = file_has_perm(current, file, FILE__IOCTL);

> Of course, that means we probably should pull that ioctl() hook too, since
> obviously there's ways to bypass it.

Right.  an hook for ->ioctl() is completly useless.  Remember that ioctl
is nothing but a magic backdoor to add syscalls.  You need to do the
permission check in code that actually knows what it is doing, not in
the dispatcher.

> 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

You should add a check where the name isactually assigned in this case.
Not that I think a check on the device name is generally a good idea..

> - if you feel THAT
> strongly that the whole concept of a security framework is that pointless,
> you're free not to use it. ;)

You've missed the point.  I never wanted to use it.  I care about the crap
that it adds to the kernel which I do want to use, develop and keep
clean.

> > 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.

Without ever seeing that module?

> 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.

The person who performs the audit can know it.  But how often will that be
the author of the LSM module? 

> 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*?

It's not bad to solve a problem.  It's a bad idea trying to 'solve' a problem
you don';t understand fully.

> 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...

Adding random hack without resolving the underlying problem is not the
way linux kernel development usually works.