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.
July 13, 2007 at 9:24 pm
Why isn’t polyinstantiated /tmp the default? It would mean instant goodbye to all those “insecure temporary file creation” vulnerabilities.
July 14, 2007 at 12:19 am
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.
July 14, 2007 at 3:30 am
Is there any big advantage of doing this over using
export TMP=$HOME/tmp
export TMPDIR=$TMP
I mean, it’s cool and all.
July 14, 2007 at 5:29 am
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.
July 14, 2007 at 4:06 pm
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.
July 20, 2007 at 9:08 am
> 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.
July 25, 2007 at 1:21 pm
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 🙂