Message-ID: <4ABA892A.9090804@schaufler-ca.com>
Date:	Wed, 23 Sep 2009 13:46:34 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	andy753421@...il.com
CC:	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] Privilege dropping security module

Andy Spencer wrote:
> 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.
>   

Hi Andy. Git is a wonderful tool, but if you want people to review
your work you need to post patches.

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

A good thing, or at least, a partial answer to #1.

>
> 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 what do you propose as an interesting use case for dpriv?

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists