public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: daw@cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: [RFC] Privilege dropping security module
Date: Thu, 24 Sep 2009 16:37:57 +0000 (UTC)	[thread overview]
Message-ID: <h9g795$9om$1@taverner.cs.berkeley.edu> (raw)
In-Reply-To: 20090923223110.GA1449@c.hsd1.tn.comcast.net

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

If I understand correctly, this isn't sufficient to run untrusted code,
because it only restricts access to the filesystem.  You gotta restrict
access to the network, interaction with other processes, and so on.
(For instance, does dpriv let the untrusted process take over another of
your processes using ptrace?)

There's a tremendous amount of research literature on building secure
sandboxes.  You should study it, if you're not familiar with it.

I suspect making all permissions recursive is going to lead to overly
permissive policies.  Suppose I want to allow read access to everything
under /lib and /usr/lib, read-execute access to everything under /bin
and /usr/bin, and read-write access to everything under /tmp.  (But I
do not want to allow any access to any other directories.)  How do I
do it?

  parent reply	other threads:[~2009-09-24 16:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-23  0:56 [RFC] Privilege dropping security module Andy Spencer
2009-09-23 20:46 ` Casey Schaufler
2009-09-23 22:31   ` Andy Spencer
2009-09-23 23:03     ` Tetsuo Handa
2009-09-24 16:37     ` David Wagner [this message]
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='h9g795$9om$1@taverner.cs.berkeley.edu' \
    --to=daw@cs.berkeley.edu \
    --cc=daw-news@cs.berkeley.edu \
    --cc=linux-kernel@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