archive mirror
 help / color / mirror / Atom feed
From: Stephen Smalley <>
To: Christoph Hellwig <>
Cc: Greg KH <>, <>,
Subject: Re: [RFC] LSM changes for 2.5.38
Date: Fri, 27 Sep 2002 15:00:03 -0400 (EDT)	[thread overview]
Message-ID: <Pine.GSO.4.33.0209271432120.11942-100000@raven> (raw)
In-Reply-To: <>

On Fri, 27 Sep 2002, Christoph Hellwig wrote:

> In 2.5 LSM hooks are part of the Linux access checks, and any reason to
> make your patch less intrusive inb 2.4 doesn't apply anymore.  Having
> two checks for the same thing is indeed very bad in will cause harm
> and maintaince burden in the long term.  Don't do it.

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?  Do you want the bad_signal() logic
pushed into the security module's task_kill() hook function?  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 (e.g. is enforcing a read-only mount a security behavior or a
functional behavior?).

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

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

Stephen D. Smalley, NAI Labs

  parent reply	other threads:[~2002-09-27 18:55 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 [this message]
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 \
    --in-reply-to=Pine.GSO.4.33.0209271432120.11942-100000@raven \ \ \ \ \ \

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