DevHeads.net

Proposing Fedora Feature for private /tmp and /var/tmp for all systemd services in Fedora 17.

It seems to be a weekly occurrence of a new CVE for some app that uses
/tmp insecurely.

I have been on a crusade for years to stop privileged services from
using /tmp and /var/tmp. These services can be potentially be
interfered by unprivileged users, potentially leading to process
escalation. The only server applications that need to use /tmp
should be for communicating with users. For example the X server, and
potentially apps that use kerberos for example sssd and nfs.gssd.
(Although maybe at some point we need to fix this.) Most apps that
rely on using /tmp to communicate with the user can be easily broken
by users having individual /tmp using pam_namespace.

systemd as of Fedora 16 has the ability to run system services with
private /tmp and /var/tmp. I would like to propose that we make this
the default in Fedora 17, or at least open a bugzilla on all system
services that we know of that use /tmp and /var/tmp to make them use
private /tmp and /var/tmp.

Comments

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Lennart Poettering at 11/07/2011 - 21:03

I am all for this, but there are two problems I see:

a) We currently default to non-shared mount propagation for /. Since the
private /tmp feature opens a new namespace for those service new mounts
won't be visible to the service.

Most folks involved agree that we should default to shared mount
propagation instead, but the problem is that there is currently no
nice way to do this. The clean solution would be to make
mount propagation a kernel mount option like any other, so that we
could just list the default for / as mount option in fstab. Only that
would make the default setting race free and sufficiently generic.

So, the clean solution would require some kernel patching, and on the
plumbers wishlist this is quite far up, but so far nobody has
volunteered to do something about this one.

A short-term hack could be to manually invoke mount on / to remount
it with shared prop, in a hacked service that just does that and nothing
else. Another option might be to simply ignore the problem...

b) We need to make clear that some services have to and may opt out of
this, for example prefdm.service, since the X11 sockets need to be
accessible by other users (as Dan already points out above).

And of course, normal users should not get a private tmp by default,
since the traditional definition of /tmp is that it is can be used to
share files between users.

But yupp, I am all for this and would be happy to change the default for
PrivateTmp= in service files from "no" to "yes" upstream.

Lennart

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Matej Cepl at 11/07/2011 - 16:38

Dne 7.11.2011 20:50, Daniel J Walsh napsal(a):
I am afraid, the proper way how to propose new Feature in Fedora is
described on <a href="http://fedoraproject.org/wiki/Features/Policy" title="http://fedoraproject.org/wiki/Features/Policy">http://fedoraproject.org/wiki/Features/Policy</a> . Throwing it
on fedora-devel is I am afraid most likely a waste of time.

Matěj

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Matthew Garrett at 11/07/2011 - 17:12

On Mon, Nov 07, 2011 at 09:38:09PM +0100, Matej Cepl wrote:
Having some public discussion of a potentially contentious feature is a
great way to help fesco make decisions. I'm personally in favour of that
happening on a mailing list rather than in the discussion page on a wiki
- it's a lot easier to follow detailed conversation that way.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Matej Cepl at 11/08/2011 - 03:35

Dne 7.11.2011 22:12, Matthew Garrett napsal(a):
Sure, I am not against discussion here, but my experience (and some
literature[1]) tells me that discussion have better tendency to succeed
when they are around some exact proposal (which is not written in stone
and the author must be flexible to accept criticism of course).

Best,

Matěj
</end-of-this-subthread>

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Daniel J Walsh at 11/08/2011 - 11:20

On 11/08/2011 02:35 AM, Matej Cepl wrote:
Well I threw one together.

<a href="https://fedoraproject.org/wiki/Features/ServicesPrivateTmp" title="https://fedoraproject.org/wiki/Features/ServicesPrivateTmp">https://fedoraproject.org/wiki/Features/ServicesPrivateTmp</a>

If I propose 3 features for Fedora 17, do I win a prize?

<a href="https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace" title="https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace">https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace</a>
<a href="https://fedoraproject.org/wiki/Features/Securecontainers" title="https://fedoraproject.org/wiki/Features/Securecontainers">https://fedoraproject.org/wiki/Features/Securecontainers</a>

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Daniel J Walsh at 11/07/2011 - 16:42

On 11/07/2011 03:38 PM, Matej Cepl wrote:
I know I just opened a couple of other features on Fedora 17. I just
wanted to open discussion on this about what would be the best way to
do this.

* Make it default in systemd
* Open bugzillas on apps that SELinux discovers uses /tmp and ask them
to change.
* Maybe a bad idea. Since admins might get confused by different /tmp(s).
* Reasonable reasons for service apps to use /tmp.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Bill Nottingham at 11/07/2011 - 17:21

Daniel J Walsh (<a href="mailto: ... at redhat dot com"> ... at redhat dot com</a>) said:
I think that would be problematic if it's applied to all units; it's a
change in behavior that they would not necessarily be expecting.

I don't see an issue with applying it to everything we ship where
appropriate.

Bill

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Simo Sorce at 11/07/2011 - 17:08

Why not simply open bugs to have apps use /var/run/<name> ?

I did something similar patching samba long ago to not export the
winbindd pipes in /tmp and sounds cleaner and avoid confusion.

The main issue with moving /tmp to /var/run or something is if you
*really* need to allow random users to write in it.

Because in that case you risk local DoS if users fill up the space (not
necessarily out of malice).

Not that filling /tmp is not a problem. and with /var/run baing a tmpfs
perhaps not a too bid deal either, at least users are not eating into /
or /var

Simo.

Simo.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Miloslav =?UTF-... at 11/08/2011 - 05:50

On Mon, Nov 7, 2011 at 10:08 PM, Simo Sorce < ... at redhat dot com> wrote:
When program A uses library B which uses library C which uses library
D which creates a temporary file, we don't want to modify the API of
all of them to pass <name> from A to D.
Mirek

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Simo Sorce at 11/08/2011 - 12:12

On Tue, 2011-11-08 at 10:50 +0100, Miloslav Trmač wrote:
Good point.

Simo.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Lennart Poettering at 11/07/2011 - 21:47

I think in some cases /tmp is preferable over /run, i.e. think
apache where users upload huge files. You don't want that on /run which
always is tmpfs. Having them on /tmp (which doesn't have to be tmpfs and
currently isn't by default) is advisable.

There's $XDG_RUNTIME_DIR for that.

But in general I belive that /run as in "runtime" is different from /tmp
as in "temporary". /run should only include sockets, pid files, shared
memory areas and other communication primitives, i.e. stuff which is
small. /tmp OTOH is something where apache should be able to store big
blobs of data that a user is uploading to a web site.

There's currently a discussion on lkml on this, regarding introduction
of RLIMIT_TMPFSQUOTA.

Lennart

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Toshio Kuratomi at 11/08/2011 - 15:59

On Tue, Nov 08, 2011 at 02:47:02AM +0100, Lennart Poettering wrote:
Moving out of tmp would also mean that directories with descriptive
filenames would become less of a risk to the unknowing admin as the new
directory would be writable by systemd, not by any user of the system.

-Toshio

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Daniel J Walsh at 11/07/2011 - 17:44

On 11/07/2011 04:08 PM, Simo Sorce wrote:

I often do this, (Probably did it with winbind.) but in some cases the
maintainer might not know how to make the change or upstream would not
want the change. Plus if we made it the default then someone
downloading a non fedora package would get it by default.

Also some packages like bash do this automatically.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Matej Cepl at 11/08/2011 - 03:30

Dne 7.11.2011 22:44, Daniel J Walsh napsal(a):
Well, if this project should ever succeeded than those bugs should have
probably patches (or somebody watching them and providing patch when
maintainer doesn't fix it herself). Otherwise we get
<a href="https://fedoraproject.org/wiki/FedoraCryptoConsolidation" title="https://fedoraproject.org/wiki/FedoraCryptoConsolidation">https://fedoraproject.org/wiki/FedoraCryptoConsolidation</a> (tons of open
bugs which are hanging around and the feature has never been implemented).

Yes, life is hard.

Matěj

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Chris Adams at 11/07/2011 - 16:44

Once upon a time, Daniel J Walsh < ... at redhat dot com> said:
Hmm, one question: is it possible for root to see these alternate tmps?

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Lennart Poettering at 11/07/2011 - 21:08

Yes and no.

Yes, since they are created as subdirectories of the real / with mkdtemp()
and thus can be found there like any other directory if you are running
in the main namespaces.

No, since there's currently no sane way to figure out the private /tmp
directory of a running service. i.e. there's currently no sane way to
figure out which directory in /tmp appears as /tmp to
avahi-daemon.service. So, while you see all the subdirs, you'll have a
hard time to figure out which one is which one.

But we could definitely add this if necessary, as a property on the bus
object of the service, which would then be queriable with "systemctl
show".

Lennart

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Chris Adams at 11/07/2011 - 21:15

Once upon a time, Lennart Poettering < ... at 0pointer dot de> said:
So are they subdirectories of / or /tmp?

How do standard tools like fuser and lsof see them? I'm thinking of
cases like "daemon gets cracked", where script-kiddie starts downloading
attempted rootkits into /tmp, or where luser does something that starts
filling up the disk, etc. If fuser/lsof can tell me correctly which
process is accessing that directory, that's probably good enough.

If it isn't too hard, that would be good as well.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Lennart Poettering at 11/07/2011 - 21:48

The latter.

If run on the main namespace all they see is that the files are in some
randomized subdir of /tmp, instead of /tmp itself.

Yes, this works as it always did. We made sure that the behaviour change
is as minimal as possible and all the accounting and discoverability is
unchanged.

Lennart

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Daniel J Walsh at 11/08/2011 - 10:07

On 11/07/2011 08:48 PM, Lennart Poettering wrote:

One suggestion would be to create a directory in /tmp at early boot.
/tmp/.systemd Which would only have root only access.

ls -ld /tmp/.systemd/
drwx------. 2 root root 40 Nov 8 09:04 /tmp/.systemd/

When systemd boots before it starts any other processes it could check
for the existance of this directory and if it has any permissions that
differ, destroy it and recreate it. Then it could create the services
directories underneath it with well known names. And bind mount those
directories over /tmp. Then it would be easier for the administrators
to find the /tmp directories.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Lennart Poettering at 11/08/2011 - 21:06

We do something similar for the X11 socket dirs, which have well-known
names. We pre-create them at boot to avoid the vulnerabilities that evil
local users might create their own subdirs in their place.

That said, I am not particularly keen on having an inflation of subdirs
in /tmp created at early boot. I'd much prefer if we design our stuff in
a robust way so that directories are created when they are needed, but
without them being guessable.

But yeah, pre-creating those dirs definitely would fix the issue, but
maybe all of this is just thinking about problems that don't exist,
since so far nobody complained too loudly about the the
non-recognizability of the private tmp dirs below /tmp. (Which obviously
is because nobody is using this yet, but well...)

So I think the current solution (fully random subdirs in /tmp) is good
enough to get things going. If there's enough reason and pressure to
make the randomized subdirs recognizable then we definitely can do
something about it, but it's probably not worth thinking too much about
that before that.

Lennart

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Henrik =?ISO-88... at 11/09/2011 - 03:06

ons 2011-11-09 klockan 02:06 +0100 skrev Lennart Poettering:

I see the static naming in a systemd owned folder as preferable for many
reasons

Less racy as only root can create the folders

Easier to identify what the folders belongs to

Easier to handle in /tmp garbage cleanup strategies

Less prone to having lots of garbage folders collect in /tmp over time.

Services keep their /tmp on restarts (for both good and bad)

Regards
Henrik

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By =?iso-8859-1?q?... at 11/08/2011 - 20:22

Daniel J Walsh wrote:
That seems like it may be a good idea, but please drop the dot. Why would that
directory need to be hidden?

Björn Persson

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Gregory Maxwell at 11/07/2011 - 22:53

On Mon, Nov 7, 2011 at 8:48 PM, Lennart Poettering < ... at 0pointer dot de> wrote:
Is the randomization required? If they were named after the
user/service that created
them (perhaps with some randomization too e.g.
/tmp/mount.fooservice.$random would be
much more discoverable and maintainable then /tmp/$random. Systemctl
show is good
and needed for automation, but my brain stores more sysadmin trivial
than I like already.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Lennart Poettering at 11/08/2011 - 07:55

Well, that way attackers might still be able fool the admin: i.e. he
could create a directory with a service name and some randomized suffix
and the admin might blindly believe that this directory belongs to the
service, even if it doesn't, but belongs to the evil attacker. Using a
fully randomized name is a bit more secure here, since the admin always
needs to check the service first for the actual directory.

Lennart

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Benny Amorsen at 11/09/2011 - 05:10

Lennart Poettering < ... at 0pointer dot de> writes:

How about making a non-world-writable directory somewhere for this
purpose, with service-named directories beneath it?

That is yet another thing for sysadms to learn about of course, unless
it is placed in /tmp itself which creates some security problems
again...

/Benny

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Miloslav =?UTF-... at 11/09/2011 - 13:22

On Wed, Nov 9, 2011 at 10:10 AM, Benny Amorsen <benny+ ... at amorsen dot dk> wrote:

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Chris Adams at 11/09/2011 - 15:11

Once upon a time, Miloslav Trmač < ... at volny dot cz> said:
Users can create entries in /tmp, which can cause a number of race
conditions.

I like the idea of using /tmp/.systemd (or /tmp/systemd, /tmp/init,
etc.) to separate the systemd-created private tmps.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Stijn Hoop at 11/08/2011 - 08:31

On Tue, 8 Nov 2011 12:55:31 +0100

But isn't the point of having namespaced /tmp that no network-facing
service is even able to create a directory in the main namespace?
In other words, if the attacker is able to create a directory in the
main namespace, you've already lost?

--Stijn

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Lennart Poettering at 11/08/2011 - 08:33

I was talking of a local attacker here, not a remote one.

Lennart

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Stijn Hoop at 11/08/2011 - 08:36

On Tue, 8 Nov 2011 13:33:00 +0100

Right, I assumed that this would be implemented for every user != root
(basically). In other words, also for normal local users. I now see
that you intend to instantiate it "only" for services by default, and
the reason why (sharing) makes sense. Thanks for the explanation.

--Stijn

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Rahul Sundaram at 11/08/2011 - 10:22

On 11/08/2011 06:06 PM, Stijn Hoop wrote:
Why is that not part of the proposal?

Rahul

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Andrew Haley at 11/08/2011 - 13:57

On 11/08/2011 02:22 PM, Rahul Sundaram wrote:
It'd break things. At the moment, the only way to share a file
with other local users is to put it into a tmp dir.

Andrew.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Chris Adams at 11/07/2011 - 23:00

Once upon a time, Gregory Maxwell < ... at gmail dot com> said:
Well, if they're subdirectories of /tmp, you'd have to deal with all the
usual /tmp attacks of known targets.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Gregory Maxwell at 11/07/2011 - 23:11

On Mon, Nov 7, 2011 at 10:00 PM, Chris Adams < ... at hiwaay dot net> wrote:
Hmph? They wouldn't be accessible to anything except root I assume.

Because they're long lived the random names shouldn't provide much
protection— and certainly not much more than partially random names
would provide. Or am I missing something?

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Chris Adams at 11/07/2011 - 23:17

Once upon a time, Gregory Maxwell < ... at gmail dot com> said:
What if a service is only started on demand? Are /tmp directories
recreated on a service restart? In either case, there'd be a point
where the /tmp subdirectory wouldn't exist; a user could log in and
create their own directory, a symlink, etc.

How does systemd handle the case where the desired subdirectory already
exists? If you use a static subdirectory name, an unclean shutdown
would leave the directories. Does systemd delete/re-create them or use
existing? In either case, users playing tricks could be a problem.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Daniel J Walsh at 11/07/2011 - 16:47

On 11/07/2011 03:44 PM, Chris Adams wrote:

I think this is a question for lennart, I am not sure how he sets them
up. If I was setting them up, I would probably set them up by default
under /run/SERVICE/tmp and bind mount over /tmp or something like
that. And I would figure the root user could see them. If he is only
mounting as tmpfs then I don't think the admin could easily get into
the namespaces to see them.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Chris Adams at 11/07/2011 - 17:25

Once upon a time, Daniel J Walsh < ... at redhat dot com> said:
I would be against something that hides stuff from root. That's a
recipie for disaster.

Re: Proposing Fedora Feature for private /tmp and /var/tmp for a

By Lennart Poettering at 11/07/2011 - 21:13

Yes, I agree.

By placing the private /tmp dirs beneath the real /tmp we tried to make
sure that the private /tmp for the services are visible to the admin
inside /tmp, are subject to automatic /tmp cleaning and are attributed
to the quota settings the admin might have set on /tmp.

Lennart