poly instantiated tmpdirs

July 13, 2007

fedorapeople.org is coming together and we’re readying for a launch $soon.

Today I got to play with poly instantiated tmpdirs. On the advice of Jeremy I talked to Dan Walsh b/c he is the knower of many security-related things. He told me to look at the pam_namespace docs . That brought me to a fairly obvious textfile. :)
Users live in /home/fedora which is a bindmount of /srv/home (for quota reasons, etc)
I setup pam_namespace.so in my pam.d/system-auth file like so:

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     required      pam_namespace.so

Then I edited my /etc/security/namespace.conf file to read:

/tmp     /srv/polyinst/tmp/             user      root,adm,apache,puppet,nagios,rpm
/var/tmp /srv/polyinst/vartmp/          user      root,adm,apache,puppet,nagios,rpm

Next I made the dirs: mkdir -p /srv/polyinst/tmp /srv/polyinst/vartmp

and as the docs said: chmod 000 /srv/polyinst/*

now I rebooted for good measure and logged in.

If I log in as root I see /tmp in /tmp where it lives

If I log in as me I see /tmp with nothing but my ssh tmpfiles in it. I make a few dirs in there to be sure.

Then I logout as me, log back in as me – the files are still there – that’s pretty good.

Then I logout as me, get someone else to log in as not-root and hunt for my dir. No joy.

So, this is all good. But it gets better. Since I put tmpdirs on the same logical device as the homedirs are on then that means I get quota’d tmpdirs for free. The quota I set on /srv (where /home is) applies to /srv/polyinst/*, too. So, we’re safe on quotas.

Users can still get to each other’s homedirs if they are so unprotected but tmpdirs don’t cause unlimited pain.

Now all I need is to get a nice tmpreaper job to traverse those paths and clean them up every now and then.

Thanks to Jeremy and Dan for the pointers. And thanks to planet fedora for first introducing me to the idea of polyinstantiated dirs.

About these ads

7 Responses to “poly instantiated tmpdirs”

  1. Kevin Kofler Says:

    Why isn’t polyinstantiated /tmp the default? It would mean instant goodbye to all those “insecure temporary file creation” vulnerabilities.

  2. skvidal Says:

    it breaks some things people expect like a shared /tmp and it does mean doing awkward things for your .X11-unix file. – take a look at namespace.init in /etc/security for an example.

    I think for servers, however, it would be hot to have a puppet recipe or a simple pkg that enabled this feature automatically.


  3. Is there any big advantage of doing this over using

    export TMP=$HOME/tmp
    export TMPDIR=$TMP

    I mean, it’s cool and all.

  4. skvidal Says:

    They’re bindmounted into place and they cannot be unset by the user. They are also not accessible to anyone other than root.

    So you end up with private, restricted tmpdirs for anyone who uses the system. That’s a lot more than just an env setting.

  5. d Says:

    How about noatime bind mounts for the users for everything except $HOME?
    (I am not sure if this is even technically possible)

    If users do a ‘find /usr’ there’s going to be a lot of atime updating,
    it would be nice if that did not happen, too much useless disk writes.


  6. > They’re bindmounted into place and they cannot be unset by
    > the user. They are also not accessible to anyone other
    > than root.
    That’s all a policy question: e.g. in ALT Linux, we do have 0700 $HOME by default (and TMPDIR in either $HOME/tmp or /tmp/.private/$USER via pam_mktemp; both are effectively 0700). That leaves properly behaving software with private tmpdirs accessible only to the user and root, covered by either $HOME or /tmp quota; broken software is still in need for a fix (which pam_namespace does only remedy but not remove in a wider world).

    That also leaves (as broken as it is but still unsolved) practice of inter-user file exchange via /tmp (or /var/tmp) in place but that seems much better to me than world-readable homedirs in most situations when I had to consider these ways.

    So it’s still a policy question: to fix/isolate/ignore broken software or to work around the class of security bugs further motivating develoopers to ignore it; to ruin age-old UNIX users’ “push” habit without offering any alternative but “pull” one or to leave it alone.

    Nice to see that there are more variants at hand though.

  7. Richard Says:

    Hello.

    I know very little about this or Windows Vista, but I was wondering how this relates to how Windows Vista shows users personal, virtual versions of directories that legacy software may have tried to write something to.

    Ever since encountering this, and problems I experience in relation (e.g. “Why does this appear here but not here even though they are looking at the ‘same’ directory?!”), I have thought it a terrible idea to lie to the user about what exists somewhere.

    Then again, I once liked the idea of not showing users anything above your $HOME through a file manager :)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: