[lkml]   [2006]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
    On Wed, 19 Apr 2006 02:40:25 EDT, Kyle Moffett said:
    > Perhaps the SELinux model should be extended to handle (dir-inode,
    > path-entry) pairs. For example, if I want to protect the /etc/shadow
    > file regardless of what tool is used to safely modify it, I would set

    Some of us think that the tools can protect /etc/shadow just fine on their
    own, and are concerned with rogue software that abuses /etc/shadow without
    bothering to safely modify it..

    > up security as follows:
    > o Protect the "/" and "/etc" directory inodes as usual under SELinux
    > (with attributes on directory inodes).
    > o Create pairs with (etc_inode,"shadow") and (etc_inode,"gshadow")
    > and apply security attributes to those potentially nonexistent pairs.

    *bzzt* wrong. Why should "gshadow" matter? (Think carefully about what
    happens when a setUID program gets exploited and used to scribble on /etc/shadow -
    black hats rarely bother to do locking and other such niceties....)

    > I'm not terribly familiar with the exact internal semantics of
    > SELinux, but that should provide a 90% solution (it fixes bind mounts

    90% doesn't give the security guys warm-and-fuzzies....

    > and namespaces). The remaining 2 issues are hardlinks and fd-
    > passing. For hardlinks you don't care about other links to that
    > data, you're concerned with protecting a particular filesystem
    > location, not particular contents, so you just need to prevent _new_
    > hardlinks to a protected (dir_inode, path_elem) pair, which doesn't
    > seem very hard.

    It's not. include/linux/security.h:

    * @inode_link:
    * Check permission before creating a new hard link to a file.
    * @old_dentry contains the dentry structure for an existing link to the file.
    * @dir contains the inode structure of the parent directory of the new link.
    * @new_dentry contains the dentry structure for the new link.
    * Return 0 if permission is granted.

    > For fd-passing, I don't know what to do. Perhaps
    > nothing.


    * @file_receive:
    * This hook allows security modules to control the ability of a process
    * to receive an open file descriptor via socket IPC.
    * @file contains the file structure being received.
    * Return 0 if permission is granted.

    Already a solved problem.

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2006-04-19 08:59    [from the cache]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site