Messages in this thread | | | Date | Wed, 23 Sep 2009 13:46:34 -0700 | From | Casey Schaufler <> | 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 >
| |