Re: Revising the remaining IPC hooks

From: Stephen Smalley (sdsat_private)
Date: Mon Oct 28 2002 - 07:54:22 PST

  • Next message: Russell Coker: "Fwd: Re: [PATCH] remove sys_security"

    The previously described changes to the remaining LSM IPC hooks have been
    committed to the lsm-2.5 BitKeeper tree.  I'd now like to raise a further
    issue with the remaining LSM IPC hooks, described below.
    The kernel developers will likely object to hook calls that are on the
    same code path as an ipcperms() check, since LSM also hooks ipcperms(),
    unless we can clearly justify their need (e.g. show that the hook provides
    finer granularity and explain why that finer granularity is needed, with
    a concrete example).  In contrast, hook calls that occur on the same code
    path as an ownership check (uid comparison) can be easily justified since
    we have no other way to enforce restrictions based on other security
    attributes (e.g. domain-based, level-based, etc).
    Three particular examples where we have hook calls on the same code path
    as ipcperms() are the calls to the *associate hooks, some of the calls to
    the *ctl hooks (but not all; some follow ownership checks instead), and
    the call to the shmat hook.  I'd like to get a sense as to whether any
    security project other than SELinux is using these hooks when they are
    called on the same code path as ipcperms(), and if so, why the hook in
    ipcperms() is insufficient for your needs.
    On Tue, 15 Oct 2002, Stephen Smalley wrote:
    > I've attached a patch against the lsm-2.5 BitKeeper tree with all of the
    > changes to the remaining IPC hooks that I've suggested so far.  Speak up
    > if you object to any of these changes.  See my earlier messages for the
    > reasons for these changes.
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Mon Oct 28 2002 - 07:55:42 PST