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 08:09:50 -0400 (EDT)	[thread overview]
Message-ID: <Pine.GSO.4.33.0209270743170.22771-100000@raven> (raw)
In-Reply-To: <>

On Fri, 27 Sep 2002, Christoph Hellwig wrote:

> Sorry, but this is bullshit (like most of the lsm changes).  Either you
> leave the capable in and say it's enough or you add your random hook
> and remove that one.  Just adding more and more hooks without thinking
> gets us exactly nowhere except to an unmaintainable codebase.

The LSM hooks are primarily restrictive, i.e. a security module can deny
access that would normally be granted by the existing Linux access checks.
Hence, the LSM patch does not remove existing access checks.  Minimal
support for permissive behavior (granting what would normally be denied)
is provided to support modularization of the capabilities logic, but this
does not require removing the capable() calls from kernel functions.  This
approach reduces the invasiveness of the patch and the likelihood of
introducing bugs into the base kernel access checking.  See the LSM papers
from Usenix Security and OLS, which should be available from

> Also is there a _real_ need to pass in all the arguments?

Define _real_.  It is true that none of the existing open source security
modules presently use this particular hook.  SELinux doesn't presently use
it, but it seems reasonable to support finer-grained control over ioperm()
than the all-or-nothing CAP_SYS_RAWIO.  Is the criteria that every hook
and every parameter to every hook must be used by an existing open source
security module?  If so, then yes, this hook can be dropped.

> Umm, you can't tell me you deny someone to initialize a module he has
> just created?

In sys_create_module, you only know the name and size of the module and
who is performing the operation.  In sys_init_module, you actually have
information about the module available.  Hence, you can make a
finer-grained decision in the module_initialize hook, and possibly deny
even after a successful module_create.  As above, SELinux doesn't use
these hooks presently.

> You don't think this should maybe be just one hook?

They are different operations, with different interpretations of the
string parameter.  If your security module is enforcing any kind of
restriction based on the parameter, then you need to distinguish them.
Again, not used by SELinux at present.

> Aha.  So every LS module knows about every single sysctl in the
> kernel.  Common, this is silly guys (and girls if there any)!

SELinux does use the sysctl hook.  It assigns security labels to sysctl
variables and enforces a consistent control whether accessed via the
sysctl() call or the /proc/sys interface.  The granularity at which you
distinguish the sysctl variables is configurable.  For example, we assign
an individual security label to /proc/sys/kernel/modprobe to suport
fine-grained control over access to it.  Most sysctl variables are grouped
into equivalence classes based on the hierarchy, but it is entirely
configurable in the security policy.

Stephen D. Smalley, NAI Labs

  parent reply	other threads:[~2002-09-27 12:05 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 [this message]
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
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.0209270743170.22771-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).