LWN.net Logo

Re: /tmp on multi-FS set-ups, or: block users from using /tmp?

From:  Ted Ts'o <tytso-AT-mit.edu>
To:  Ivan Shmakov <oneingray-AT-gmail.com>
Subject:  Re: /tmp on multi-FS set-ups, or: block users from using /tmp?
Date:  Sat, 26 May 2012 14:32:15 -0400
Message-ID:  <20120526183215.GA11165@thunk.org>
Cc:  debian-devel-AT-lists.debian.org
Archive-link:  Article, Thread

On Sat, May 26, 2012 at 09:29:30PM +0700, Ivan Shmakov wrote:
> 	… But that makes me recall a solution to both the /tmp and quota
> 	issues I've seen somewhere: use ~/tmp/ instead of /tmp.  This
> 	way, user's temporary files will be subject to exactly the same
> 	limits as all the other his or her files.
> 
> 	(Still, we may need to identify the software that ignores TMPDIR
> 	and tries to write to /tmp unconditionally.)
> 
>  > (Snark aside, does tmpfs support quotas yet/will it ever?)

These days I'd argue that multi-user is such a corner case that it's
not worth optimizing for it as far as defaults are concerned.  If
you're trying to run a secure multi-user system, you need to be an
expert system administrator, keep up with all security patches, and
even then, good luck to you.  (The reality is that these days, no
matter what OS you're talking about, shell == root.  And that's
probably even true on the most unusably locked down SELinux system.)

What I'd do in that situation is to use per-user /tmp directories,
where each user would get its own mount namespace, and so each user
would have its own /tmp --- either a bind-mounted $(HOME)/tmp to /tmp
if you want to enforce quotas that way, or a separate tmpfs for each
user --- and then you can specify the size of the per-user tmpfs
mounted on each user's version of /tmp.

Cheers,

						- Ted


-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120526183215.GA11165@thunk.org




(Log in to post comments)

Surrender?

Posted Jun 1, 2012 17:10 UTC (Fri) by jmorris42 (subscriber, #2203) [Link]

> shell == root

If shell == root and fork(2) == shell then fork(2) == root. That means any ability to execute code outside a sandbox == root so just forget about the whole notion of security. No. I'm not Pollyanna or anything but I'm not quite that cynical.

Surrender?

Posted Jun 1, 2012 17:20 UTC (Fri) by hummassa (subscriber, #307) [Link]

You should be (that much cynical). Once you break from the first jail, you are free, because you can break from the second, and third, and scale privileges, etc. Either you are inside the sandbox or loose. There is nowhere "in the middle".

Surrender?

Posted Jun 1, 2012 18:07 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

That's pretty much true. Normal Linux user accounts can become root or kernel easily - local kernel exploits are published about once a year and probably quite a number of unpublished exploits exist.

So yes, your only hope is to contain untrusted code inside of a sandbox. And even that is non-trivial - just ask Google.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds