archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <>
To: Stephen Smalley <>
Cc: Greg KH <>,,
Subject: Re: [RFC] LSM changes for 2.5.38
Date: Tue, 1 Oct 2002 18:06:11 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <Pine.GSO.4.33.0209271432120.11942-100000@raven>; from on Fri, Sep 27, 2002 at 03:00:03PM -0400

On Fri, Sep 27, 2002 at 03:00:03PM -0400, Stephen Smalley wrote:
> So you want to move the 'if (turn_on && !capable(CAP_SYS_RAWIO)) return
> -EPERM;' from the base kernel into the security module's ioperm() hook
> function, in addition to whatever additional logic the module may
> implement?  [Assuming for the moment that we kept the ioperm() hook, even
> though that isn't likely given its current lack of use and
> architecture-specific nature].

> If so, what about the rest of the kernel access checking logic?  Do you
> want all of the permission() logic pushed into the security module's
> inode_permission() hook function?

permission() switches into per-fs code.

> Do you want the bad_signal() logic
> pushed into the security module's task_kill() hook function?

Only the capable() check.  Unless of course we make uid/gid checking optional.
Which seems like a very bad idea given the mess even with just the current LSM

> That kind of
> change was considered and discussed on linux-security-module long ago, but
> it will yield a very invasive patch for very little gain.  It also
> requires cleanly separating all access checking logic from functional
> logic (it is sometimes fairly intertwined) and determining exactly which
> is which

Umm.  Clean and nicely separated code is a lot of gain.  Making Linux's
access clean instead of a lot more messy is a good think.  Much better than
any feature addition.  (Unless, of course, you get paid for adding

> (e.g. is enforcing a read-only mount a security behavior or a
> functional behavior?).

For the kernel it's a functional behavior.  The administrator can chose
to apply it for security reasons, but that's policy and thus not the
kernel's issue.

> > Show me a useful example that needs this argument.
> Do you want every process that can use ioperm() to be able to access the
> full range of ports accessible by that call?  If not, then you need
> something finer-grained than CAP_SYS_RAWIO.  But as I said, we don't
> presently use this hook, and it is architecture-dependent.

Okay, this does actually makes sense.  Point taken.

> > And WTF is the use a security policy that checks module arguments?  Do
> > you want to disallow options that are quotes from books on the index
> > or not political correct enough for a US state agency?
> The LSM module_initialize hook is called with a pointer to the kernel's
> copy of the relocated module image with the struct module header.  Hence,
> the security module is free to perform whatever validation it wants on
> that image prior to the execution of the init function.  But if the
> criteria is that there must be a specific existing security module that
> uses the hook, then this one will go away too.

Yes, a hook without a intree user or at least a properly defined and
available out-of-tree user is pointless.

  reply	other threads:[~2002-10-01 17:08 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
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 [this message]
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).