linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Mon, 30 Sep 2002 10:19:18 -0400	[thread overview]
Message-ID: <200209301419.g8UEJI6E001699@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Fri, 27 Sep 2002 19:59:19 BST." <20020927195919.A4635@infradead.org>

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

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;

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?

> Given that we really want to fine-grained control who's netdevice can get what
> names we'd` better place a hook in dev_alloc_name.

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

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

> And that's my whole point: LSM adds random hooks all over the place without
> even thinking what they intend to protect.

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. Yes, there are some hooks that are unused by anything
at the current time (and there's discussion on the LSM list about pruning those
hooks), but I'll bet if you ask "why is hook XYZ in there?" on the LSM list,
somebody will be able to reply with "to close the hole of ABC".



-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


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

  reply	other threads:[~2002-09-30 14:16 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 [this message]
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
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=200209301419.g8UEJI6E001699@turing-police.cc.vt.edu \
    --to=valdis.kletnieks@vt.edu \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@wirex.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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