From: Andy Spencer <andy753421@gmail.com>
To: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC] Privilege dropping security module
Date: Wed, 23 Sep 2009 00:56:44 +0000 [thread overview]
Message-ID: <20090923005644.GA28244@c.hsd1.tn.comcast.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 2885 bytes --]
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
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
next reply other threads:[~2009-09-23 1:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-23 0:56 Andy Spencer [this message]
2009-09-23 20:46 ` [RFC] Privilege dropping security module Casey Schaufler
2009-09-23 22:31 ` Andy Spencer
2009-09-23 23:03 ` Tetsuo Handa
2009-09-24 16:37 ` David Wagner
2009-09-25 7:22 ` Andy Spencer
2009-09-25 20:48 ` David Wagner
2009-09-26 21:09 ` Andy Spencer
2009-09-27 0:28 ` David Wagner
2009-10-01 7:38 ` Pavel Machek
2009-10-01 9:15 ` Andy Spencer
2009-10-01 10:42 ` Pavel Machek
2009-09-23 21:31 ` [RFC][PATCH] " Andy Spencer
2009-09-24 16:25 ` Casey Schaufler
2009-09-25 10:06 ` Andy Spencer
2009-09-25 16:23 ` Casey Schaufler
2009-09-26 21:35 ` Andy Spencer
2009-09-28 5:38 ` Rob Meijer
2009-09-25 21:00 ` David Wagner
2009-09-29 7:36 ` Andy Spencer
2009-09-29 7:10 ` [RFC][PATCH] Permission masking security module (was dpriv) Andy Spencer
2009-09-29 17:44 ` Greg KH
2009-09-30 0:18 ` Andy Spencer
2009-10-01 2:33 ` Casey Schaufler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090923005644.GA28244@c.hsd1.tn.comcast.net \
--to=andy753421@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox