archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <>
Subject: Re: [RFC] LSM changes for 2.5.38
Date: Wed, 2 Oct 2002 19:39:40 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>; from on Wed, Oct 02, 2002 at 01:55:14PM -0400

On Wed, Oct 02, 2002 at 01:55:14PM -0400, 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.
      			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

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

  reply	other threads:[~2002-10-02 18:34 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-27  4:32 [RFC] LSM changes for 2.5.38 Christoph Hellwig
2002-09-26 22:51 ` Greg KH
2002-09-27 16:48   ` Christoph Hellwig
2002-09-27 16:55     ` Greg KH
2002-09-27 17:01       ` Christoph Hellwig
2002-09-27 17:24         ` Greg KH
2002-09-27 12:09 ` Stephen Smalley
2002-09-27 16:34   ` Greg KH
2002-09-27 16:55   ` Christoph Hellwig
2002-09-27 18:09     ` Valdis.Kletnieks
2002-09-27 18:19       ` Christoph Hellwig
2002-09-27 18:54         ` Valdis.Kletnieks
2002-09-27 18:59           ` Christoph Hellwig
2002-09-30 14:19             ` Valdis.Kletnieks
2002-09-30 14:51               ` Alan Cox
2002-10-01 16:55               ` Christoph Hellwig
2002-10-02 17:55                 ` Valdis.Kletnieks
2002-10-02 18:39                   ` Christoph Hellwig [this message]
2002-10-02 22:55                     ` Seth Arnold
2002-10-02 23:07                       ` Alan Cox
2002-09-27 19:00     ` Stephen Smalley
2002-10-01 17:06       ` Christoph Hellwig
2002-09-30  9:08 ` Chris Wright
  -- strict thread matches above, loose matches on Subject: below --
2002-09-26 20:25 Greg KH
2002-09-26 20:26 ` Greg KH
2002-09-26 20:27   ` Greg KH
2002-09-26 20:28     ` Greg KH
2002-09-26 20:28       ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).