archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <>
Subject: Re: [RFC] LSM changes for 2.5.38
Date: Tue, 1 Oct 2002 17:55:00 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>; from on Mon, Sep 30, 2002 at 10:19:18AM -0400

On Mon, Sep 30, 2002 at 10:19:18AM -0400, wrote:
> On Fri, 27 Sep 2002 19:59:19 BST, Christoph Hellwig said:
> > insmod doesn't require modules to be in /lib/modules.
> This would probably be closed by this code in sys_create_module():
>         /* check that we have permission to do this */
>         error = security_ops->module_ops->create_module(name, size);
>         if (error)
>                 goto err1;

It wouldn't.  sys_create_module doesn't get the absolute path of the module passed.

> Similarly, there are other hooks that will stop renaming of the interface (I
> have to admit I haven't had enough caffeine to verify whether doing a /bin/mv
> to rename an interface will change the name that's presented to the iptables
> rulesets), or did you have other "rename" methods in mind?

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.

> However, you're missing the point - I was using that as *AN EXAMPLE* of "you
> might want to check what parameters are being passed".  Are you prepared to
> make the same sort of analysis for *EVERY* parameter of *every* module, and
> every combination thereof (including interacting parameters of different
> modules)?

If I wanted to implement a trusted system: yes.  I you wanted and paid me
enough for it: also yes.  And that's exactly my point.  If you want a
trusted system you're not done by adding a few hooks in places that look
strategic, you have to a proper audit of _all_ code in your project.

Let me repeat _ALL_ code.  Yes, you have to understand WTF is going on,
and that's where LSM fail miserably.

> In order to assert that the hook to check parameters in module loading is
> useless, you'd have to verify that there exist *NO* modules that can have their
> security status changed by changing the parameters.

Noooh!  You got something very wrong.  You (or rather the LSM people) want to
add a new feature, and they have to prove it useful.  An as long as there is no
standard on what a specific string in a module option means for the kernel
in the end such a check is pretty damn useless.

> And even more importantly,
> you'd have to make this a permanent restriction on module parameters,
> which puts the onus on "getting it right" on the module author, rather than
> on the LSM author who's in a better position to know what is/isn't acceptable
> for his module.

How does the lsm author know what the option x=y means for my module?  In my
module a it means print lots of nice windowish nagscreen, but in my friend
Paul's module (who works for the German BND) it means scribble all over my
disk because only someone who has stolen the notebook might be stupid
enough to use such a silly option.

See what I mean?

> And quite a bit of thought *did* go into it - a *LOT* of those hooks got added
> along the way precisely *because* the writers of a module found that they were
> trying to enforce a policy, and found it could be backdoored by means like
> module parameters.

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

  parent reply	other threads:[~2002-10-01 16:52 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 [this message]
2002-10-02 17:55                 ` Valdis.Kletnieks
2002-10-02 18:39                   ` Christoph Hellwig
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).