lkml.org 
[lkml]   [2009]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject[RFC] Privilege dropping security module
    I started work on a Linux Security Module called dpriv a few days ago
    and would like to get some feedback. It's by no means ready to be
    included in the kernel, but I'm sure there are many things that I could
    have done better so suggestions are welcome.

    The code is available from gitweb and the dpriv branch of my tree:

    git://lug.rose-hulman.edu/~spenceal/linux-dev dpriv

    http://lug.rose-hulman.edu/git/?p=~spenceal/linux-dev;f=security/dpriv;hb=refs/heads/dpriv


    I'll start off with a quick FAQ
    -------------------------------
    Q: Why another LSM, don't we have enough already?
    A: As far as I know there are several rather unique things about dpriv
    when compared to other LSMs. (it's also been a good way for me to
    familiarize myself with the kernel)

    Q: So what's unique about dpriv?
    A: - Dpriv can be used by any user, not just by root
    - The "policy" is created at runtime instead of fixed beforehand
    - It does *not* implement Mandatory Access Control


    Now for how it works
    --------------------
    - Everything is controlled though a securityfs interface which consists
    of three files: "stage", "policy", and "control".

    - Policies are created by writing lines to the stage file and then
    writing the "commit" command to the control file. "Committing" the
    policy merges the staged policy into the actual policy (the "policy"
    file). Note that privileges can only be dropped during a commit, and
    afterwards there is no way to get them back.

    - Policies are effective for the process which created them and are also
    copied to all it's child processes.

    - For example, the following commands will set the root filesystem
    read-only with the exception of allowing execute permission in /bin/
    and write permission in /tmp/. (note that directory permission are
    uppercase and file permissions are lowercase, both are recursive)

    $ echo r--R-X / > /sys/kernel/security/dpriv/stage
    $ echo r-xR-X /bin > /sys/kernel/security/dpriv/stage
    $ echo rw-RWX /tmp > /sys/kernel/security/dpriv/stage
    $ echo commit > /sys/kernel/security/dpriv/control


    And some technical details
    --------------------------
    (subject to change)

    - Dpriv stores a list of active and staged permissions for each process
    in current->cred->security. Each permissions line consists of a mode
    mask and the inode that it is effective for.

    - When determining access rights for an inode: if the inode is in the
    list of active permissions, use that mask, else recursively fetch (and
    merge) the permissions from the inodes parents

    (to do this, all the parents for hard links/mounts will need to be
    known and stored in the inode somehow, possibly using extended
    attributes, I haven't completely worked this out yet)

    - Permissions for things other than files could be implemented as well,
    but I haven't started working on those either.


    Let me know what you think
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2009-09-23 03:07    [W:0.021 / U:30.664 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site