Re: proposal: per-user temporary directories on by default?
* Kevin Kreamer [...] | Ok, I've done some thinking on this as well, and this is what I've | come up with. I don't think making sure that the base directory is | owned by root will protect you, as that would still allow an | attacker to put a tmpdir in most system areas. What we really need | is to make sure that the tmpdir is created where the admin wants, not | where the user wants. Indeed, you are right. Having it be 711 + owned by root would make it pretty safe, though I don't want to do that, since suddenly /var/run/sudo or something would be 711 and then you'd have a _big_ problem. | Since the helper has to be setuid, and has to runnable by anyone | (since the PAM stuff uses the permissions of whoever is logging in), | we can't pass the path into the helper. It has to already know where | to make the path. So, it seems to me that the best approach is to | have both pam_tmpdir.so and the helper read the configuration file | independently to find out where to put the tmpdir. However, since | the helper won't know what service is being used, and therefore won't | know which pam.d file to read, we'll have to use a completely | independent config file (/etc/pam-tmpdir.conf or something like that). Either that, or pass the service name on the command line. it's significantly less work to parse one's own configuration file than parsing the PAM config file, so having a separate config file for libpam-tmpdir might make sense. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: proposal: per-user temporary directories on by default?
Tollef Fog Heen <[EMAIL PROTECTED]> writes: > * Kevin Kreamer > [...] > > | [1] My solution as to how to get the path from libpam-tmpdir to > | pam-tmpdir-helper was to pass it on the command line. But, since > | anyone can run pam-tmpdir-helper, anyone can create any tmpdir they > | like anywhere on the system. Very bad. > > Adding a sanity check that the base directory is owned by root, would > that suffice? > > I think I'll have to think about this a little. Ok, I've done some thinking on this as well, and this is what I've come up with. I don't think making sure that the base directory is owned by root will protect you, as that would still allow an attacker to put a tmpdir in most system areas. What we really need is to make sure that the tmpdir is created where the admin wants, not where the user wants. Since the helper has to be setuid, and has to runnable by anyone (since the PAM stuff uses the permissions of whoever is logging in), we can't pass the path into the helper. It has to already know where to make the path. So, it seems to me that the best approach is to have both pam_tmpdir.so and the helper read the configuration file independently to find out where to put the tmpdir. However, since the helper won't know what service is being used, and therefore won't know which pam.d file to read, we'll have to use a completely independent config file (/etc/pam-tmpdir.conf or something like that). What do you think? Kevin pgpWqpo21fdOd.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
* Kevin Kreamer | Tollef Fog Heen <[EMAIL PROTECTED]> writes: | > ATM, TMPDIR is defined using #define in libpam-tmpdir's source. | > Patches for having that as a run-time configuration are accepted. | | I recently posted to debian-devel a patch to do this (not sure | whether you saw it or not). I saw it, thanks [...] | [1] My solution as to how to get the path from libpam-tmpdir to | pam-tmpdir-helper was to pass it on the command line. But, since | anyone can run pam-tmpdir-helper, anyone can create any tmpdir they | like anywhere on the system. Very bad. Adding a sanity check that the base directory is owned by root, would that suffice? I think I'll have to think about this a little. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: proposal: per-user temporary directories on by default?
Tollef Fog Heen <[EMAIL PROTECTED]> writes: > ATM, TMPDIR is defined using #define in libpam-tmpdir's source. > Patches for having that as a run-time configuration are accepted. I recently posted to debian-devel a patch to do this (not sure whether you saw it or not). However, at the time, I didn't realise that /sbin/pam-tmpdir-helper was a setuid root program. Purely my fault; I didn't check. Anyway, that patch opens up a security hole[1], so please don't apply it. Thanks, Kevin [1] My solution as to how to get the path from libpam-tmpdir to pam-tmpdir-helper was to pass it on the command line. But, since anyone can run pam-tmpdir-helper, anyone can create any tmpdir they like anywhere on the system. Very bad. pgpys4KpeW8AX.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
Tollef Fog Heen <[EMAIL PROTECTED]> writes:
> ATM, TMPDIR is defined using #define in libpam-tmpdir's source.
> Patches for having that as a run-time configuration are accepted.
Attached is a patch to allow you to specify TMPDIR in the relevent
pam.d file, like so:
session optional pam_tmpdir.so tmpdir=/tmp/users
It does not (yet) expand ~, $HOME, or the like. I'd like someone to
look it over to make sure I didn't open any security holes or cause
any stupid bugs. (I do realise that it trusts the contents of the
pam.d file... not sure how paranoid to be about that.)
Thanks,
Kevin
Index: pam-tmpdir-helper.c
===
--- pam-tmpdir-helper.c (revision 1)
+++ pam-tmpdir-helper.c (working copy)
@@ -27,6 +27,8 @@
#define SYSUSRTMP "/tmp/user"
+char *tmpdir;
+
/* some syslogging */
static void _log_err(int err, const char *format, ...)
@@ -47,48 +49,48 @@
struct stat statbuf;
mode_t old_umask;
- ret = lstat(SYSUSRTMP,&statbuf);
+ ret = lstat(tmpdir,&statbuf);
if (ret == -1 && errno != ENOENT) {
-snprintf(logbuf,sizeof logbuf,"lstat SYSUSRTMP failed: %s\n", strerror(errno));
+snprintf(logbuf,sizeof logbuf,"lstat tmpdir failed: %s\n", strerror(errno));
_log_err(LOG_NOTICE, "%s", logbuf);
return 1;
} else if (ret != -1 && statbuf.st_uid != 0) {
/* Somebody else than root has grabbed /tmp/user. Bad, bad, bad. */
snprintf(logbuf,sizeof logbuf,"%s is owned by uid %d instead of root "
- "(uid 0). Failed to create safe $TMPDIR\n", SYSUSRTMP,
+ "(uid 0). Failed to create safe $TMPDIR\n", tmpdir,
statbuf.st_uid);
_log_err(LOG_ERR, "%s", logbuf);
return 1;
} else if (ret != -1 && !S_ISDIR(statbuf.st_mode)) {
-snprintf(logbuf,sizeof logbuf,"%s is not a directory. Failed to create safe $TMPDIR\n", SYSUSRTMP);
+snprintf(logbuf,sizeof logbuf,"%s is not a directory. Failed to create safe $TMPDIR\n", tmpdir);
_log_err(LOG_NOTICE, "%s", logbuf);
return 1;
} else if (ret != -1 && ((statbuf.st_mode & S_IWGRP) || (statbuf.st_mode & S_IWOTH))) {
snprintf(logbuf,sizeof logbuf,"%s is group or world writable. "
- "Failed to create safe $TMPDIR\n", SYSUSRTMP);
+ "Failed to create safe $TMPDIR\n", tmpdir);
_log_err(LOG_NOTICE, "%s", logbuf);
return 1;
} else if (ret != -1 && !(statbuf.st_mode & S_IXOTH)) {
snprintf(logbuf,sizeof logbuf,"%s is not world searchable. "
- "Failed to create safe $TMPDIR\n", SYSUSRTMP);
+ "Failed to create safe $TMPDIR\n", tmpdir);
_log_err(LOG_NOTICE, "%s", logbuf);
return 1;
} else if (ret == -1 && errno == ENOENT) {
old_umask = umask();
-if (mkdir(SYSUSRTMP,0711) == -1) {
- snprintf(logbuf,sizeof logbuf,"mkdir SYSUSRTMP failed: %s\n", strerror(errno));
+if (mkdir(tmpdir,0711) == -1) {
+ snprintf(logbuf,sizeof logbuf,"mkdir tmpdir failed: %s\n", strerror(errno));
_log_err(LOG_NOTICE, "%s", logbuf);
return 1;
}
umask(old_umask);
-if (chown(SYSUSRTMP,0,0) == -1) {
- snprintf(logbuf,sizeof logbuf,"chown 0:0 SYSUSRTMP failed: %s\n", strerror(errno));
+if (chown(tmpdir,0,0) == -1) {
+ snprintf(logbuf,sizeof logbuf,"chown 0:0 tmpdir failed: %s\n", strerror(errno));
_log_err(LOG_NOTICE, "%s", logbuf);
return 1;
}
}
- if (snprintf(buf, sizeof buf, "%s/%d",SYSUSRTMP,getuid()) == -1) {
+ if (snprintf(buf, sizeof buf, "%s/%d",tmpdir,getuid()) == -1) {
return 1;
}
ret = lstat(buf,&statbuf);
@@ -131,5 +133,29 @@
}
int main(int argc, char **argv) {
+ /* Parse our command line arguments. We assume that
+ * we will either receive one argument (the tmpdir path),
+ * or none at all (in which case, we set tmpdir to be SYSUSRTMP).
+ */
+
+ if (argc == 2) {
+ if ((tmpdir = malloc(strlen(argv[1]) + 1)) == NULL) {
+ _log_err(LOG_ERR, "malloc failed. Out of memory.");
+ return 1;
+ }
+ strcpy(tmpdir, argv[1]);
+ } else if (argc == 1) {
+ if ((tmpdir = malloc(strlen(SYSUSRTMP) + 1)) == NULL) {
+ _log_err(LOG_ERR, "malloc failed. Out of memory.");
+ return 1;
+ }
+ strcpy(tmpdir, SYSUSRTMP);
+ } else {
+ _log_err(LOG_ERR, "Incorrect number of arguments. Giving up.");
+ return 1;
+ }
+
+ /* At this point, tmpdir should contain a valid TMPDIR path. */
+
return make_tmp_directory();
}
Index: pam_tmpdir.c
===
--- pam_tmpdir.c (revision 1)
+++ pam_tmpdir.c (working copy)
@@ -43,7 +43,10 @@
#define SYSUSRTMP "/tmp/user"
#define PAM_TMPDIR_HELPER "/sbin/pam-tmpdir-helper"
+#define TMPDIR_INTRO "tmpdir="
+char *tmpdir = NULL;
+
static int set_environment(pam_handle_t *pamh);
static int make_tmp_directory(pam_handle_t *pamh);
@@ -85,16 +88,45 @@
#define PAM_ENV_SILENT 0x04
#define PAM_NEW_ENV_FILE0x10
+static int set_tmpdir(int argc, c
Re: proposal: per-user temporary directories on by default?
On Fri, 25 Jul 2003 22:52:43 -0400, Joey Hess wrote: > Dwayne C. Litzenberger wrote: >> - in the meantime, tmpreaper cleans up /tmp/bob > > Just FWIW, but a multiuser system that is running tmpreaper is insecure. > The bugs apparantly cannot be fixed, but I can write up an exploit if you > pay me. :-) Private temporary directories will help to some extent. It's not a complete solution, because people can still play tricks with the temporary files created by setuid programs they have run. On the other hand if we could hold down the attack to only setuid programs (which one hopes are more careful anyhow) it would be a benefit. > Directory size matters less and less anyway, modern fileystems use > btrees, and this includes ext3 with -O dir_index. Not default yet, > apparently. If it was the deciding factor in getting this adopted, I would write the 20-line patch to make libpam-tmpdir use multi-level directories. But as you say I don't think it would be a big deal for most (if any) systems. -- Martin
Re: proposal: per-user temporary directories on by default?
On Fri, 25 Jul 2003 13:27:04 -0600, Dwayne C. Litzenberger wrote: > I'm not trying to start a flamewar. You asked "Is there *any* reason why > defaulting TMPDIR=/tmp/ is inferior to TMPDIR=/tmp?", I > answered, and now you're being hostile and dismissive. That is a reasonable question to ask. I think Dwayne has pointed out two reasons: 1- Creating per-user directories might be expensive. 2- There are some problems with the current libpam implementation. #1 is not quite invalid, but I don't think it is the overriding concern here. The disk used by an empty directory is negligible. Machines which are very tiny, or have thousands of users can set up their own system. There are a large number of insecure scripts out there, and very likely still some applications with tmpfile holes. I don't think a minor or probably negligible performance issue justifies leaving these problems open. #2 is a reason to fix libpam-tmpdir, not to stick with a shared /tmp. Dwayne, can you think of anything aside from those two? > - Bob logs in. /tmp/bob is created > - Bob leaves his terminal xlocked for a week - in the meantime, tmpreaper > cleans up /tmp/bob - Mllory creates a new /tmp/bob, allowing for later > attacks - Bob comes back and runs some shell script he wrote (under the > assumption > that /tmp/bob would always be safe -- something which would not have > happened with the regular /tmp) > - Mallory executes a symlink attack As Dwayne probably discovered, this would be impossible because the actual directory is (say) /tmp/users/1001, and only root can write to /tmp/users. > As someone else mentioned in this thread, libpam-tmpdir creates a single > "/tmp/user" and "/tmp/user/$uid/". If "/tmp/user" already exists but with > the wrong permissions, it fails. Yes, that is a problem with the current code. It is not a problem with the general idea of per-user temp directories. There are various ways to fix it, including - Creating /tmp/user as root during startup before Mallory can log in - Putting this somewhere other than /tmp -- say /usertmp, mode 711. (But I suppose people will think it's ugly and I can't think of a good name.) Perhaps tmpreaper could be set up not to never reap /tmp/user. It is a little ironic that the issue of making sure /tmp/user is the real one is exactly what I hope to avoid by moving away from 1777 /tmp. > Oddly, it doesn't seem to set the environment variables properly when > using "su", though it seems to be creating the correct directories. But > neither does pam_env.so (anyone know why?). Does su mop the environment? -- Martin
Re: proposal: per-user temporary directories on by default?
On Fri, 25 Jul 2003 19:33:25 -0600, Dwayne C. Litzenberger wrote: > On Sat, Jul 26, 2003 at 09:16:44AM +1000, Matthew Palmer wrote: >> > Not necessarily. With the current /tmp system, the only directory >> > entries that are created are the ones that are actually needed at any >> > given time. If we switch to /tmp/username, then there will be a >> > directory entry in /tmp for *every user* who ever logs on. >> >> Hang about. You seem to have two different systems running here. One >> where files get cleaned out of /tmp sometimes, and one where they don't. > > No, I'm not, actually. tmpreaper works by absolute time, like 7 days. > *Many* users can log into a system during that amount of time, but they > probably won't all be creating temporary files that they don't clean up > shortly after. With libpam-tmpdir, it doesn't matter whether the user > doesn't even have a home directory (i.e. system users, qmail users, > nobody, etc) -- they will all cause an entry to be created in /tmp/user. I'm having trouble imagining a system where the "working set" of active uids is so large that creating one directory for each of them stresses the filesystem. A machine with hundreds of users probably ought to use ext3 directory hashes, reiserfs or xfs. > Do I think using libpam-tmpdir by default would work? Yes, at least for > the short term. However, I also think it's a band-aid solution for the > real problem (excessive /tmp vulnerabilities), and it introduces problems > of its own. I think the real problem is the original misdesign of /tmp: requiring systems to have a world-writable directory, and making a large number of programs deal with the issues of world-writable directories was a horrible idea. Why make programs and users be careful when all they really want is some private scratch space? -- Martin
Re: proposal: per-user temporary directories on by default?
On Fri, 25 Jul 2003 23:11:04 -0400, Matt Zimmerman wrote: > On Fri, Jul 25, 2003 at 07:33:25PM -0600, Dwayne C. Litzenberger wrote: > >> >> Personally, I'd rather see a better set of tools for programmers to use >> to create temporary files. tmpfile(3) is horribly inadequade for a lot >> of things (like when you need to know the filename of the file you just >> created) > > mkstemp(3) Just by the by: mkstemp(3) is inadequate for some cases, such as creating temporary files to pass to gcc. mkstemp changes the final characters of the filename, but the file extension is important to gcc (and other programs). Sometimes you need /tmp/tmp12345.i. I mention this just as an example where developers with the best of intentions have no choice but to use a nonstandard method to create files. Certainly this can be done safely, but to return to my original point: it's good if there is additional protection beyond hoping that every program is correct. -- Martin
Re: proposal: per-user temporary directories on by default?
* Nick Bannon | On Sat, Jul 26, 2003 at 02:52:48PM +0200, Andreas Metzler wrote: | > Bernd Eckenfels <[EMAIL PROTECTED]> wrote: | > > If you default to ~/tmp/ or ~/.temp/ or something like this, you get the | > > hashing for free, and you only need quota on the home partition. | > | > It was pointed out already that this is not necessarily a good idea, | > e.g. when /home is on NFS. | | When /home is on NFS, then ~/tmp is not optimal, but it's still a | reasonable and secure default. ATM, TMPDIR is defined using #define in libpam-tmpdir's source. Patches for having that as a run-time configuration are accepted. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: proposal: per-user temporary directories on by default?
On Sat, Jul 26, 2003 at 02:52:48PM +0200, Andreas Metzler wrote: > Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > > If you default to ~/tmp/ or ~/.temp/ or something like this, you get the > > hashing for free, and you only need quota on the home partition. > > It was pointed out already that this is not necessarily a good idea, > e.g. when /home is on NFS. When /home is on NFS, then ~/tmp is not optimal, but it's still a reasonable and secure default. > Additionally you cannot run tmpreaper on > ~/tmp/ without starting a big information campain, "everthing under ~/ > was always sacred." > cu andreas If you turn on quotas on /home then there's less need to run tmpreaper. (Less need to run as root, anyway - perhaps a user will find it a convenient tool to clean up ~/tmp) Nick. -- Nick Bannon | "I made this letter longer than usual because [EMAIL PROTECTED] | I lack the time to make it shorter." - Pascal
Re: proposal: per-user temporary directories on by default?
On Sat, Jul 26, 2003 at 02:52:48PM +0200, Andreas Metzler wrote: > It was pointed out already that this is not necessarily a good idea, > e.g. when /home is on NFS. Additionally you cannot run tmpreaper on > ~/tmp/ without starting a big information campain, "everthing under ~/ > was always sacred." I put all my "important files without a better spot" under ~/tmp. Actually maybe running tmpreaper on this directory would be a good idea ;-), although I don't dare risk it. The fact remains though that I use /tmp/bam and /home/bam/tmp for different purposes. The point about /home being NFS is an important one, some programs don't function properly with /tmp being NFS. (then again, some programs debian/stable don't cope with NFS on /home either, but thats a topic for another thread, most noteably Gnome IIRC). -- Brian May <[EMAIL PROTECTED]>
Re: proposal: per-user temporary directories on by default?
On Fri, Jul 25, 2003 at 11:11:04PM -0400, Matt Zimmerman wrote: > mkstemp(3) mkstemp returns a file descriptor, how... [reads the manpage again]... oh. %-) > mkdtemp(3) I see. Sigh. I guess it's hopeless to expect that everyone will write their programs properly. Oh well. I give in. Use libpam-tmpdir. -- Dwayne C. Litzenberger <[EMAIL PROTECTED]> The attachment is an OpenPGP (PGP/MIME) signature, which can be used to verify the authenticity of this message. See the message headers for more information. pgpLWKfjKP603.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > On Fri, Jul 25, 2003 at 08:44:17AM -0500, Steve Greenland wrote: >> Or, for all I care, we can default to /tmp/u/username. Just don't bother >> me about it. > If you default to ~/tmp/ or ~/.temp/ or something like this, you get the > hashing for free, and you only need quota on the home partition. It was pointed out already that this is not necessarily a good idea, e.g. when /home is on NFS. Additionally you cannot run tmpreaper on ~/tmp/ without starting a big information campain, "everthing under ~/ was always sacred." cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: proposal: per-user temporary directories on by default?
On Fri, Jul 25, 2003 at 08:44:17AM -0500, Steve Greenland wrote: > Or, for all I care, we can default to /tmp/u/username. Just don't bother > me about it. If you default to ~/tmp/ or ~/.temp/ or something like this, you get the hashing for free, and you only need quota on the home partition. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: proposal: per-user temporary directories on by default?
On Fri, Jul 25, 2003 at 07:33:25PM -0600, Dwayne C. Litzenberger wrote: > > Personally, I'd rather see a better set of tools for programmers to use to > create temporary files. tmpfile(3) is horribly inadequade for a lot of > things (like when you need to know the filename of the file you just > created) mkstemp(3) > , and I have yet to see a good interface for securely creating > directories. > mkdtemp(3) -- - mdz
Re: proposal: per-user temporary directories on by default?
Dwayne C. Litzenberger wrote: > - in the meantime, tmpreaper cleans up /tmp/bob Just FWIW, but a multiuser system that is running tmpreaper is insecure. The bugs apparantly cannot be fixed, but I can write up an exploit if you pay me. :-) Directory size matters less and less anyway, modern fileystems use btrees, and this includes ext3 with -O dir_index. Not default yet, apparently. -- see shy jo pgpBajRgtED0Z.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
On Fri, Jul 25, 2003 at 07:33:25PM -0600, Dwayne C. Litzenberger wrote: > > Personally, I'd rather see a better set of tools for programmers to use to > create temporary files. tmpfile(3) is horribly inadequade for a lot of > things (like when you need to know the filename of the file you just > created), and I have yet to see a good interface for securely creating > directories. > mkdtemp()'s OK, isn't it? It's easier to get directory creation right because of the semantics of mkdir(). -- Colin Watson [EMAIL PROTECTED]
Re: proposal: per-user temporary directories on by default?
On Sat, Jul 26, 2003 at 09:16:44AM +1000, Matthew Palmer wrote: > > Not necessarily. With the current /tmp system, the only directory entries > > that are created are the ones that are actually needed at any given time. > > If we switch to /tmp/username, then there will be a directory entry in /tmp > > for *every user* who ever logs on. > > Hang about. You seem to have two different systems running here. One where > files get cleaned out of /tmp sometimes, and one where they don't. No, I'm not, actually. tmpreaper works by absolute time, like 7 days. *Many* users can log into a system during that amount of time, but they probably won't all be creating temporary files that they don't clean up shortly after. With libpam-tmpdir, it doesn't matter whether the user doesn't even have a home directory (i.e. system users, qmail users, nobody, etc) -- they will all cause an entry to be created in /tmp/user. Pretty soon, normal users are going to start using multiple uids in a session. (For example, each user could have their GnuPG/SSH/whatever private keys in a separate user's home directory that only GnuPG/ssh-add/whatever has access to -- this would prevent people with access to your terminal while you're away from your desk from getting copies of those keys to run dictionary attacks on. Users could also have Wine/Mozilla running as a different user, so that security holes don't compromise their home dirs. I'm sure there are other applications for this.) If normal users start using 5 uids each, that's 5 directory entries per user in /tmp/user. Yet, none of the programs running under these uids might ever write files to $TMPDIR. > I would have thought that either of tmpreaper or clean-on-boot would > solve the excess directories problem. There are no shortage of programs > that leave crap in /tmp after they're finished on my system, at any rate. > Splitting those up into multiple per-user directories could only improve > matters, surely? How many of those programs create a new file for every user that ever logs in? That's what this proposal creates. Do I think using libpam-tmpdir by default would work? Yes, at least for the short term. However, I also think it's a band-aid solution for the real problem (excessive /tmp vulnerabilities), and it introduces problems of its own. Personally, I'd rather see a better set of tools for programmers to use to create temporary files. tmpfile(3) is horribly inadequade for a lot of things (like when you need to know the filename of the file you just created), and I have yet to see a good interface for securely creating directories. -- Dwayne C. Litzenberger <[EMAIL PROTECTED]> The attachment is an OpenPGP (PGP/MIME) signature, which can be used to verify the authenticity of this message. See the message headers for more information. pgpKeCwFrujGt.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
On Fri, Jul 25, 2003 at 01:27:04PM -0600, Dwayne C. Litzenberger wrote: > On Fri, Jul 25, 2003 at 08:43:20AM -0500, Steve Greenland wrote: > > On 24-Jul-03, 17:56 (CDT), "Dwayne C. Litzenberger" <[EMAIL PROTECTED]> > > wrote: > > > Systems with large numbers of users (and normally use, for example > > > /home/u/username), and filesystem which doesn't like large numbers of > > > entries quickly might have performance problems. > > > > In which case, having all the files in /tmp is likely to be worse. > > Not necessarily. With the current /tmp system, the only directory entries > that are created are the ones that are actually needed at any given time. > If we switch to /tmp/username, then there will be a directory entry in /tmp > for *every user* who ever logs on. Hang about. You seem to have two different systems running here. One where files get cleaned out of /tmp sometimes, and one where they don't. Is there something fundamental to the user-tmp-dir thing that requires all user temp dirs to exist at all times? I would have thought that either of tmpreaper or clean-on-boot would solve the excess directories problem. There are no shortage of programs that leave crap in /tmp after they're finished on my system, at any rate. Splitting those up into multiple per-user directories could only improve matters, surely? - Matt
Re: proposal: per-user temporary directories on by default?
On Fri, Jul 25, 2003 at 08:43:20AM -0500, Steve Greenland wrote: > On 24-Jul-03, 17:56 (CDT), "Dwayne C. Litzenberger" <[EMAIL PROTECTED]> > wrote: > > On Thu, Jul 24, 2003 at 02:50:05PM -0500, Steve Greenland wrote: > > > Please don't. Is there *any* reason why defaulting > > > TMPDIR=/tmp/ is inferior to TMPDIR=/tmp? > > > > Systems with large numbers of users (and normally use, for example > > /home/u/username), and filesystem which doesn't like large numbers of > > entries quickly might have performance problems. > > In which case, having all the files in /tmp is likely to be worse. Not necessarily. With the current /tmp system, the only directory entries that are created are the ones that are actually needed at any given time. If we switch to /tmp/username, then there will be a directory entry in /tmp for *every user* who ever logs on. > Look, we're talking about defaults here. Defaults are not suitable for > all situations, but simply the best average choice. Very large (and > very small) systems will always have to make adjustments to suit their > particular needs. It's part of the deal of running a large system. But > for the majority of Debian users, we should pick the best option and not > bother them about it. > > Or, for all I care, we can default to /tmp/u/username. Just don't bother > me about it. I'm not trying to start a flamewar. You asked "Is there *any* reason why defaulting TMPDIR=/tmp/ is inferior to TMPDIR=/tmp?", I answered, and now you're being hostile and dismissive. > > And then there's the issue of making *really sure* that /tmp/username > > always exists and has the correct permissions, > > Please follow along. We're talking about automating this in a PAM, which > would create the directory and set TMPDIR. I *am* following along. Only doing it in PAM will probably not be sufficient. Consider the following scenario: - Bob logs in. /tmp/bob is created - Bob leaves his terminal xlocked for a week - in the meantime, tmpreaper cleans up /tmp/bob - Mllory creates a new /tmp/bob, allowing for later attacks - Bob comes back and runs some shell script he wrote (under the assumption that /tmp/bob would always be safe -- something which would not have happened with the regular /tmp) - Mallory executes a symlink attack Incidentally, I just installed libpam-tmpdir, and I found out that it actually handles this much more intelligently than we thought (the above attack is actually not possible with libpam-tmpdir, although Mallory could still create his own "/tmp/user", which would interfere with libpam-tmpdir's operation.) As someone else mentioned in this thread, libpam-tmpdir creates a single "/tmp/user" and "/tmp/user/$uid/". If "/tmp/user" already exists but with the wrong permissions, it fails. Oddly, it doesn't seem to set the environment variables properly when using "su", though it seems to be creating the correct directories. But neither does pam_env.so (anyone know why?). -- Dwayne C. Litzenberger <[EMAIL PROTECTED]> The attachment is an OpenPGP (PGP/MIME) signature, which can be used to verify the authenticity of this message. See the message headers for more information. pgpy6ABNUk7h0.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
(Sorry for the dup, Dwayne, meant to send this to the list.) On 24-Jul-03, 17:56 (CDT), "Dwayne C. Litzenberger" <[EMAIL PROTECTED]> wrote: > On Thu, Jul 24, 2003 at 02:50:05PM -0500, Steve Greenland wrote: > > Please don't. Is there *any* reason why defaulting > > TMPDIR=/tmp/ is inferior to TMPDIR=/tmp? > > Systems with large numbers of users (and normally use, for example > /home/u/username), and filesystem which doesn't like large numbers of > entries quickly might have performance problems. In which case, having all the files in /tmp is likely to be worse. Look, we're talking about defaults here. Defaults are not suitable for all situations, but simply the best average choice. Very large (and very small) systems will always have to make adjustments to suit their particular needs. It's part of the deal of running a large system. But for the majority of Debian users, we should pick the best option and not bother them about it. Or, for all I care, we can default to /tmp/u/username. Just don't bother me about it. > And then there's the issue of making *really sure* that /tmp/username > always exists and has the correct permissions, Please follow along. We're talking about automating this in a PAM, which would create the directory and set TMPDIR. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: proposal: per-user temporary directories on by default?
On Thu, 24 Jul 2003 16:56:50 -0600, Dwayne C. Litzenberger wrote: > On Thu, Jul 24, 2003 at 02:50:05PM -0500, Steve Greenland wrote: >> Please don't. Is there *any* reason why defaulting >> TMPDIR=/tmp/ is inferior to TMPDIR=/tmp? > > Systems with large numbers of users (and normally use, for example > /home/u/username), and filesystem which doesn't like large numbers of > entries quickly might have performance problems. The issue is having a number of directories under /tmp/users/, each with a moderate number of files, vs having a large number of files directly under /tmp. It will depend on the particular case but I don't think the first will be be worse than the second. Indeed the two-level case with /tmp/users/ is closer to the setup you mention. The tmpdir for an active user is likely to be in the dcache much of the time, which means that accessing files in it may well be faster than looking through an enormous /tmp/ shared by all users. If people are running a tmpreaper, then it will reap the directories of any users who have not used them for n days. On machines with many users who are intermittently active the case is quite different to /home, where all the directories have to exist all the time. Administrators for whom this is a concern can always override it from a profile script. Anyhow, I don't think a highly speculative possible performance issue justifies neglecting a concrete security improvement that would have effectively protected users from a number of existing problems. > And then there's the issue of making *really sure* that /tmp/username > always exists and has the correct permissions, I think doing this once and properly in libpam-tmpdir is more likely to be secure than various administrators or programs trying to get it right. I have already done a quick audit of the source and filed some (fairly minor) bugs; other people are welcome to do do too. I am not saying that libpam-tmpdir is eternal and perfect in its current state. There are some issues that could be improved. But I would like Debian to move towards per-user tmp as a general idea. > otherwise this would be > worse, because once we do this, people will probably stop caring about > creating temporary files securely. Well, those people would be pretty damn foolish, because the issue will still exist on almost all other Unix systems or on systems that reset TMPDIR. -- Martin
Re: proposal: per-user temporary directories on by default?
On Thu, 24 Jul 2003 16:58:33 -0500, Steve Langasek wrote: > Does the PAM module *create* /tmp/ if it's not there? Actually it is /tmp/users/ at the moment, and yes, it creates both levels securely. -- Martin
Re: proposal: per-user temporary directories on by default?
On Thu, Jul 24, 2003 at 02:50:05PM -0500, Steve Greenland wrote: > Please don't. Is there *any* reason why defaulting > TMPDIR=/tmp/ is inferior to TMPDIR=/tmp? Systems with large numbers of users (and normally use, for example /home/u/username), and filesystem which doesn't like large numbers of entries quickly might have performance problems. And then there's the issue of making *really sure* that /tmp/username always exists and has the correct permissions, otherwise this would be worse, because once we do this, people will probably stop caring about creating temporary files securely. -- Dwayne C. Litzenberger <[EMAIL PROTECTED]> The attachment is an OpenPGP (PGP/MIME) signature, which can be used to verify the authenticity of this message. See the message headers for more information. pgpkyxeE8MZ73.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
On Thu, Jul 24, 2003 at 02:50:05PM -0500, Steve Greenland wrote: > On 24-Jul-03, 11:11 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote: > > I think that getting the package to make the necessary modifications of > > the pam files would be a good first step. > yes. > > Possibly with a debconf > > question first. Then we could see about integrating it into base-config. > Please don't. Is there *any* reason why defaulting > TMPDIR=/tmp/ is inferior to TMPDIR=/tmp? If not, just do it, > don't bother people with unnecesary questions. Does the PAM module *create* /tmp/ if it's not there? -- Steve Langasek postmodern programmer pgp29Ix07bpxu.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
On Thu, Jul 24, 2003 at 03:13:40PM +1000, Martin Pool wrote: > > Martin Pool wrote: > >> At the least I would like to see Debian prompt for this at installation > >> much as it does for shadow passwords. Ideally it would be on by > >> default. > > I'm all for this idea. > Thanks. What needs to be done to have it adopted? > > Since I use static per-user in home tmp directories > > I have not looked at libpam-tmpdir though. I suppose that enabling it > > currently requires making some modifications to many of the pam.d files? > Yes, it does. This is a slight problem: it would be nice if there were a > way to say "this session module should apply to all services", but I don't > think there's any way to do that in PAM. It could be done in either > libpam or a Debian script that generates the files, but it's not strictly > needed. This should soon be possible, by making the relevant changes to /etc/pam.d/other and /etc/pam.d/common-session (not yet present in the Debian packages). The support for this layout in the PAM packages is well underway, but I don't think anyone's begun work yet on an "update-pam" interface for managing these two config files. -- Steve Langasek postmodern programmer pgpl8TEi4XIwe.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
On 24-Jul-03, 11:11 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote: > I think that getting the package to make the necessary modifications of > the pam files would be a good first step. yes. > Possibly with a debconf > question first. Then we could see about integrating it into base-config. Please don't. Is there *any* reason why defaulting TMPDIR=/tmp/ is inferior to TMPDIR=/tmp? If not, just do it, don't bother people with unnecesary questions. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: proposal: per-user temporary directories on by default?
Martin Pool wrote: > Thanks. What needs to be done to have it adopted? I think that getting the package to make the necessary modifications of the pam files would be a good first step. Possibly with a debconf question first. Then we could see about integrating it into base-config. -- see shy jo pgp4ejOvHIXFH.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
On Wed, 23 Jul 2003 17:14:09 -0400, Joey Hess wrote: > Martin Pool wrote: >> At the least I would like to see Debian prompt for this at installation >> much as it does for shadow passwords. Ideally it would be on by >> default. > > I'm all for this idea. Thanks. What needs to be done to have it adopted? > Since I use static per-user in home tmp directories > I have not looked at libpam-tmpdir though. I suppose that enabling it > currently requires making some modifications to many of the pam.d files? Yes, it does. This is a slight problem: it would be nice if there were a way to say "this session module should apply to all services", but I don't think there's any way to do that in PAM. It could be done in either libpam or a Debian script that generates the files, but it's not strictly needed. For the time being I suppose it could just be applied to the services for which it is most relevant: login, ssh, gdm, kdm, xdm, etc. -- Martin
Re: proposal: per-user temporary directories on by default?
On Wed, 23 Jul 2003 11:26:58 +0200, Tollef Fog Heen wrote: > * Christoph Hellwig > > | On Wed, Jul 23, 2003 at 02:09:28PM +1000, Martin Pool wrote: > | > There is already a PAM modules, libpam-tmpdir which automatically sets > | > this up on login by creating a per-user directory under /tmp and > | > pointing TMPDIR at it. Despite the scary low version number of 0.04 > | > it seems to work reliably and presumably any bugs could be fixed. > | > | Nice idea, wrong implementation. Let login fork the login shell with > | CLONE_NEWNS and do a VFS-binding from ~/tmp to /tmp. Presumably you'd want to add this through a PAM module rather than hacking it right into login, otherwise gdm, ssh etc wouldn't be consistent. Having decided to do it through PAM, is it really necessary to change the VFS rather than setting $TMPDIR? Making it impossible to get to the real /tmp makes it a bit more intrusive and potentially confusing than really seems necessary. Given that there is a TMPDIR variable which is obeyed in most cases, using it seems to be easier than remapping /tmp. Fixing programs which are hardcoded to /tmp to use TMPDIR is pretty trivial. Making sure that operations in a world-writable directory are secure can be very hard. A PAM module which does VFS setup would be pretty cool, but I don't think that's the one Debian should use by default. > CLONE_NEWNS is 2.4.19 and higher only. Also, ~ might be on NFS or similar > where you don't want to put temporary files. > (And about the version number of libpam-tmpdir: it could just as easy have > been 0.4, in which case nobody would have thought it was «scaringly > low». Yes, I'm upstream for it.) Thanks for writing it. I couldn't find any web pages about libpam-tmpdir other than the Debian package. It might be nice to put up just a small one so that it's easier for other systems to find. > If we were to put it in as default, I'd like to clean up the code a bit.. > it should be safe, but it could use a little tidying up. There are small issues I'll discuss offline. I'm not sure if this is featurism, but you might add a parameter to allow people to set the path. /tmp/users/$uid/ is a good default but people might possibly want it in /home or elsewhere for disk space or other reasons. -- Martin
Re: proposal: per-user temporary directories on by default?
Martin Pool wrote: > At the least I would like to see Debian prompt for this at > installation much as it does for shadow passwords. Ideally it would > be on by default. I'm all for this idea. Since I use static per-user in home tmp directories I have not looked at libpam-tmpdir though. I suppose that enabling it currently requires making some modifications to many of the pam.d files? -- see shy jo pgpPqB1JS2eDO.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
On Wed, Jul 23, 2003 at 09:23:23AM -0500, Chad Walstrom wrote: > On Wed, Jul 23, 2003 at 12:35:15AM -0600, Joel Baker wrote: > > Except for OS types or versions that don't support that, or people who > > actually want /tmp when they explicitly request it, even if > > TMPDIR=~/tmp is fine most of the time. > > For example, when your home directory is actually on an NFS mounted > volume. Changing your TMPDIR to ~/tmp is pretty much insane in that > case, setting yourself up for painfully slow write operations on files > that SHOULD be considered "throw-away" anyway. ~/tmp was just an example. You can aswell use $foofilesystem/$USER/tmp or whatever you want. The big difference is that we actually make this identical to /tmp for that particular user.
Re: proposal: per-user temporary directories on by default?
On Wed, Jul 23, 2003 at 12:35:15AM -0600, Joel Baker wrote: > Except for OS types or versions that don't support that, or people who > actually want /tmp when they explicitly request it, even if > TMPDIR=~/tmp is fine most of the time. For example, when your home directory is actually on an NFS mounted volume. Changing your TMPDIR to ~/tmp is pretty much insane in that case, setting yourself up for painfully slow write operations on files that SHOULD be considered "throw-away" anyway. Now, per-user temp directories to some configurable local disk or tmpfs would be ideal. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */
Re: proposal: per-user temporary directories on by default?
* Christoph Hellwig | On Wed, Jul 23, 2003 at 02:09:28PM +1000, Martin Pool wrote: | > There is already a PAM modules, libpam-tmpdir which automatically sets | > this up on login by creating a per-user directory under /tmp and | > pointing TMPDIR at it. Despite the scary low version number of 0.04 | > it seems to work reliably and presumably any bugs could be fixed. | | Nice idea, wrong implementation. Let login fork the login shell with | CLONE_NEWNS and do a VFS-binding from ~/tmp to /tmp. CLONE_NEWNS is 2.4.19 and higher only. Also, ~ might be on NFS or similar where you don't want to put temporary files. (And about the version number of libpam-tmpdir: it could just as easy have been 0.4, in which case nobody would have thought it was «scaringly low». Yes, I'm upstream for it.) If we were to put it in as default, I'd like to clean up the code a bit.. it should be safe, but it could use a little tidying up. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: proposal: per-user temporary directories on by default?
On Wed, Jul 23, 2003 at 08:21:09AM +0200, Christoph Hellwig wrote: > On Wed, Jul 23, 2003 at 02:09:28PM +1000, Martin Pool wrote: > > There is already a PAM modules, libpam-tmpdir which automatically sets > > this up on login by creating a per-user directory under /tmp and > > pointing TMPDIR at it. Despite the scary low version number of 0.04 > > it seems to work reliably and presumably any bugs could be fixed. > > Nice idea, wrong implementation. Let login fork the login shell with > CLONE_NEWNS and do a VFS-binding from ~/tmp to /tmp. Except for OS types or versions that don't support that, or people who actually want /tmp when they explicitly request it, even if TMPDIR=~/tmp is fine most of the time. I can't think of a better way to get admins to simply turn it off completely than to make it completely override /tmp and have no good way around that. -- Joel Baker <[EMAIL PROTECTED]> pgpPpSvz4iJ0W.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
On Wed, Jul 23, 2003 at 02:09:28PM +1000, Martin Pool wrote: > There is already a PAM modules, libpam-tmpdir which automatically sets > this up on login by creating a per-user directory under /tmp and > pointing TMPDIR at it. Despite the scary low version number of 0.04 > it seems to work reliably and presumably any bugs could be fixed. Nice idea, wrong implementation. Let login fork the login shell with CLONE_NEWNS and do a VFS-binding from ~/tmp to /tmp.
