6 messages, 2 authors, 2014-05-02 · open the first message on its own page
From: Andy Lutomirski <luto@amacapital.net>
Date: 2014-05-01 22:20:21
Is it supposed to work? It does, but this seems odd. If the current behavior is intentional, then I'll submit a patch to add a new mount flag to turn off ipc. If it's not, then I'll submit a patch to fix it. -- Andy Lutomirski AMA Capital Management, LLC
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: 2014-05-01 22:34:32
On Thu, May 01, 2014 at 03:20:00PM -0700, Andy Lutomirski wrote:
Is it supposed to work?
Why the hell not? Same as opening a device node on r/o filesystem for write, or doing the same with FIFO.
From: Andy Lutomirski <luto@amacapital.net>
Date: 2014-05-01 23:00:49
On Thu, May 1, 2014 at 3:34 PM, Al Viro [off-list ref] wrote:
On Thu, May 01, 2014 at 03:20:00PM -0700, Andy Lutomirski wrote:quoted
Is it supposed to work?Why the hell not? Same as opening a device node on r/o filesystem for write, or doing the same with FIFO.
You can't bind a socket on a read-only fs, so I thought it was a fair question. I'll write a patch to add MS_NOIPCCONNECT and MNT_NOIPCCONNECT to block connect on unix sockets and open on fifos. This will be useful for sandboxes that want to prevent sandboxed programs from accessing undesirable parts of the outside world. --Andy
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: 2014-05-01 23:51:35
On Thu, May 01, 2014 at 04:00:49PM -0700, Andy Lutomirski wrote:
On Thu, May 1, 2014 at 3:34 PM, Al Viro [off-list ref] wrote:quoted
On Thu, May 01, 2014 at 03:20:00PM -0700, Andy Lutomirski wrote:quoted
Is it supposed to work?Why the hell not? Same as opening a device node on r/o filesystem for write, or doing the same with FIFO.You can't bind a socket on a read-only fs, so I thought it was a fair question. I'll write a patch to add MS_NOIPCCONNECT and MNT_NOIPCCONNECT to block connect on unix sockets and open on fifos. This will be useful for sandboxes that want to prevent sandboxed programs from accessing undesirable parts of the outside world.
Sigh... Don't expose those FIFOs et.al. to them, then. mount --bind /dev/null <pathname> as part of setting the sucker up. And if you *are* blindly exposing the host filesystems to them wholesale, sockets and fifos are the least of your problems, even if you do that read-only.
From: Andy Lutomirski <luto@amacapital.net>
Date: 2014-05-01 23:57:34
On Thu, May 1, 2014 at 4:51 PM, Al Viro [off-list ref] wrote:
On Thu, May 01, 2014 at 04:00:49PM -0700, Andy Lutomirski wrote:quoted
On Thu, May 1, 2014 at 3:34 PM, Al Viro [off-list ref] wrote:quoted
On Thu, May 01, 2014 at 03:20:00PM -0700, Andy Lutomirski wrote:quoted
Is it supposed to work?Why the hell not? Same as opening a device node on r/o filesystem for write, or doing the same with FIFO.You can't bind a socket on a read-only fs, so I thought it was a fair question. I'll write a patch to add MS_NOIPCCONNECT and MNT_NOIPCCONNECT to block connect on unix sockets and open on fifos. This will be useful for sandboxes that want to prevent sandboxed programs from accessing undesirable parts of the outside world.Sigh... Don't expose those FIFOs et.al. to them, then. mount --bind /dev/null <pathname> as part of setting the sucker up. And if you *are* blindly exposing the host filesystems to them wholesale, sockets and fifos are the least of your problems, even if you do that read-only.
Why? Suppose I bind-mount /usr into a private namespace with nosuid,nodev,ro. How can you use it to attack anything? The only thing I've thought of is to open fifos and connect to sockets. I'm assuming that there's a pid namespace blocking ptrace and such and a network namespace blocking abstract sockets. --Andy
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: 2014-05-02 00:56:59
On Thu, May 01, 2014 at 04:57:13PM -0700, Andy Lutomirski wrote:
Suppose I bind-mount /usr into a private namespace with nosuid,nodev,ro. How can you use it to attack anything? The only thing I've thought of is to open fifos and connect to sockets. I'm assuming that there's a pid namespace blocking ptrace and such and a network namespace blocking abstract sockets.
How many FIFOs and sockets are there in your /usr? Here all I see outside of /dev, /run and /tmp (across seven boxen; I can check more, but I really doubt it'll catch anything) is the grand total of 4: /lib/cryptsetup/passfifo /var/lib/oprofile/opd_pipe /var/lib/nfs/rpc_pipefs/nfs/clnt0/idmap /var/lib/nfs/rpc_pipefs/gssd/clntXX/gssd None of those in /usr and I don't believe that you seriously propose to bind e.g. /lib/cryptsetup into your sandbox. And while we are at it, exposing host /usr is *not* a good idea - if nothing else, it gives quite a bit of information about the versions of software installed on the host. Ability to watch atime of /usr/bin/* also might be interesting, etc. Do you, by any chance, plan to expose the host /tmp or /run? Or rpc_pipefs, for that matter...