[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090923223110.GA1449@c.hsd1.tn.comcast.net>
Date: Wed, 23 Sep 2009 22:31:10 +0000
From: Andy Spencer <andy753421@...il.com>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] Privilege dropping security module
> Hi Andy. Git is a wonderful tool, but if you want people to review
> your work you need to post patches.
Thanks for letting me know, I've posted a separate message with patch.
> And what do you propose as an interesting use case for dpriv?
I think the two most important things about dpriv is that it can be used
by ordinary users and that is can create policies programmatically.
Being able to use dpriv as a non root user is pretty strait forward. For
example, a user of a multi-user system may want to try some untrusted
code without risking access to the rest of the system:
$ cd ~/my_project
$ echo rxRX / > /sys/kernel/security/dpriv/stage
$ echo X $HOME > /sys/kernel/security/dpriv/stage
$ echo rwxRWX $HOME/my_project > /sys/kernel/security/dpriv/stage
$ echo commit > /sys/kernel/security/dpriv/control
$ patch < untrusted.patch
$ make && ./src/some_exe
The above example also demonstrates how dpriv can be used
programmatically. That is, a policy for allowing read-write-exec access
to build and test tools in ~/my_project didn't have to exist ahead of
time.
A more realistic example might be for a virtual hosting web server where
you want apache to only have access to the files for the current virtual
host.
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists