Re: per-user temp directories by default?
On Thu, Nov 03, 2005 at 11:16:43PM -0500, Noah Meyerhans wrote: I have little operational experience with this PAM module, though. Does it cause problems for certain apps? If so, could these problems be solved with a less simplistic PAM configuration? The only one I've encountered so far is gdm[1], although I haven't been using libpam-tmpdir for all that long. [1] http://bugs.debian.org/332466 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
On Fri, Nov 04, 2005 at 02:08:41PM +0200, Lars Wirzenius wrote: I don't think the suggestion was to make TMP=~/tmp, but TMP=/tmp/$USER, where /tmp/$USER is owned by the user in question and is inaccessible to others. Or perhaps I read too much into the proposal? That's pretty close... currently, libpam-tmpdir uses /tmp/user/$UID. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Fr den 4. Nov 2005 um 13:36 schrieb Jon Dowland: ...alongside the private keys in ~/.gnupg? Well, you can configure gnupg to write secret keys to a secure medium. Am Fr den 4. Nov 2005 um 15:46 schrieb Noah Meyerhans: First of all, libpam_tmpdir doesn't put $TMP in $HOME. Second, we're Ah, ok. In some mails I understand to put it in $HOME. One more directory level under /tmp shouldn't be a problem. talking about the *default* configuration. If you're doing something Me too. Also pam configuration can be overwritten from dpkg. (If you didn't touch it this will be done without asking a question. Also if it seems to be a good idea to use per user tmp just ask the sysadmins by a debconf question. with encrypted swap or $HOME on NFS, you've already diverged quite a bit from the default configuration, so your security would not be broken even if $TMP was in $HOME. You'd simply have one single line to delete from the default pam configuration. Well, not pam configuration for this changes. (For other like LDAP or such you need to) So the config files will be silentely overwritten. Gruß Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED] Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBQ2/Pw5+OKpjRpO3lAQIzQwf/V/GTrGJX4BTn8+a4lBsqlCzssgUSk7aT Oo2s2GQ3KfJXMNwp/BLxGc/yAhYaNLmysfNEJDrzLaeIUYsohRbzIGiSFCEGmSJf cOd3yWVuv6vmX5+4pvi3cHk26fteWm22YVcQNwb0sX9JPDWrA5pA6BZUGA9sSkQb 9cFa8VWgJoVA13rbrLKU/Z/gFLZfXF4KQCh0986tR3W4uknRHMBPPyynEVjlfEqb 97AHS3pSyhcawgcmEtRpsKn1K3xtfyv3fqMCIfJ9DNYdKZq9fZT6fUdI2mL8e74E GH18UKyHstHa2h5D18r4S63A+unDbaF9lbZLI9k0olkIi+UVKyBDhA== =q86y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
On Saturday 05 November 2005 11:27 pm, Brian May wrote: Can't we just pick one standard name for the environment variable and stick to it? If we do that, I'd request that it be $TMPDIR, as that's what SUSv3 has standardized. -- Brian M. Carlson [EMAIL PROTECTED] Running on GNU/kFreeBSD; i686-pc-kfreebsd-gnu Support alternative kernels in Debian! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
Noah == Noah Meyerhans [EMAIL PROTECTED] writes: Noah Within the security team, there has recently been some talk Noah of pushing for per-user temp directories by default in etch. Noah I'd like to see what people's reaction to such a proposal Noah would be. I have something similar (and probably not as good...) in my zshenv file, I seem to recall the PAM solution is better and more secure (possible because it runs as root), but I can't remember the details. My solution will not work if an attacker has already created the directory as another user... if [[ ! -a /tmp/$USERNAME ]] then mkdir /tmp/$USERNAME fi if [[ -d /tmp/$USERNAME ! -h /tmp/$USERNAME -O /tmp/$USERNAME ]] then export TMP=/tmp/$USERNAME else export TMP=/tmp fi export TMPDIR=$TMP export TEMP=$TMP export TMPPREFIX=$TMP/zsh --- The only problem I have had is chroots (including pbuilder). If you access the chroot in such a way that preserves the environment, you either have to change the chroot somehow ensure /tmp/$USERNAME exists, or change both TMP, TMPDIR and TEMP to /tmp inside the chroot. For pbuilder this can be done by adding: export TMP=/tmp export TMPDIR=/tmp export TEMP=/tmp to pbuilderrc. For dchroot, the only solution I can think of right now is to bind mount /tmp inside the chroot. This will also allow access to X sockets, gdm sockets, ssh-agent sockets, Kerberos tickets, etc. Could be considered good or bad depending on the reason for the chroot... --- On this subject, I find it irritating that we need so many environment variables to indicate where /tmp is. Not only that, but some programs don't even give a clear understandable error if the directory doesn't exist. So if you miss one, beware, you might get unpredictable errors. Can't we just pick one standard name for the environment variable and stick to it? -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default? Thu, 3 Nov 2005 23:16:43 -0500)
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: session optional pam_tmpdir.so Another potential problem is if a run a suid (non-root) program that attempts to create a file in $TMP. But it's suid, so it doesn't run under my uid, and doesn't have permissions to write to $TMP. But I've never run across that -- suid programs are pretty uncommon. Some buildds use sudo rather than fakeroot. This could cause problems for them... (like the /dev/null one being discussed on #debian-devel) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
hi, On Thu, Nov 03, 2005 at 11:16:43PM -0500, Noah Meyerhans wrote: Within the security team, there has recently been some talk of pushing for per-user temp directories by default in etch. I'd like to see what people's reaction to such a proposal would be. granted that i don't know the specifics of this module, but from my perspective i think it would be reasonable to include this in the default setup. There are a number of outstanding insecure tempfile vulnerabilities, and there has been some talk that they're both too numerous and of low enough impact that they're not even worth releasing DSAs for. Never the less, they are potentially dangerous and should be dealt with on some level. We believe that using libpam_tmpdir by default should make nearly all of these vulnerabilities cease to be relevant (there are some well, cease to be relevant for releases after etch, maybe... but you still have the lifespan of woody + sarge + etch during which they would still be relevant. so this isn't exactly an immediate benefit :) sean -- signature.asc Description: Digital signature
Re: per-user temp directories by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Fr den 4. Nov 2005 um 5:16 schrieb Noah Meyerhans: Within the security team, there has recently been some talk of pushing for per-user temp directories by default in etch. I'd like to see what That whould be no good idea for security environment where you do special think to secure /tmp (make it in memory and encrypt swap). With tempdir in users home all applications like for example gpg write temporary files to this location which ends up unencrypted on a disk or, more bad over an unsecure NFS share to the fileserver. Please don't do this by default as it break the security of many, many systems! Regards Klaus Ethgen - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED] Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBQ2tNcJ+OKpjRpO3lAQIDjQf5AWUOrviF019g2c1YntGlqAJS/TzRpwhi KhHQK/PWuRwl/NmrALidtHe2YUhyisKa58wQ/kPRqTvf9aKrIlAMRFZFK4zYENO9 1441k2AuGmjkcoxMAptLYdc/rRujDJkxeVWwxmkmTj1nzzLVriCgLJgVoJZVzC+O FXbWa5e7JyWASvYDQqkH2aut0RZwn9g43So8Y+SQOFCRC/qSXFkRIapsOe+PeXGc 9UtMw6BFQ8NrGyAsTaQBl6/AmcSEkOiY8BaJKrBoHfDrhjz6lftBvOoDOfGIYjbB 8cAasv+2eHUiv2FgHkK2imreo5TgjGx2MoFLHu51wwjNg2qtfC7Lvg== =eXIw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
pe, 2005-11-04 kello 13:00 +0100, Klaus Ethgen kirjoitti: Am Fr den 4. Nov 2005 um 5:16 schrieb Noah Meyerhans: Within the security team, there has recently been some talk of pushing for per-user temp directories by default in etch. I'd like to see what That whould be no good idea for security environment where you do special think to secure /tmp (make it in memory and encrypt swap). With tempdir in users home all applications like for example gpg write temporary files to this location which ends up unencrypted on a disk or, more bad over an unsecure NFS share to the fileserver. Please don't do this by default as it break the security of many, many systems! I don't think the suggestion was to make TMP=~/tmp, but TMP=/tmp/$USER, where /tmp/$USER is owned by the user in question and is inaccessible to others. Or perhaps I read too much into the proposal? -- Communication via acronyms is rfs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
Klaus Ethgen [EMAIL PROTECTED] wrote: Am Fr den 4. Nov 2005 um 5:16 schrieb Noah Meyerhans: Within the security team, there has recently been some talk of pushing for per-user temp directories by default in etch. I'd like to see what That whould be no good idea for security environment where you do special think to secure /tmp (make it in memory and encrypt swap). With tempdir in users home all applications like for example gpg write temporary files to this location which ends up unencrypted on a disk or, more bad over an unsecure NFS share to the fileserver. What do the security people mean with per-user temp directories? It's clear that $HOME/tmp would be bad, but /tmp/$USERNAME/ with proper permissions doesn't sound so awkward. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: per-user temp directories by default?
On Fri, Nov 04, 2005 at 01:00:48PM +0100, Klaus Ethgen wrote: With tempdir in users home all applications like for example gpg write temporary files to this location which ends up unencrypted on a disk ...alongside the private keys in ~/.gnupg? -- Jon Dowland http://jon.dowland.name/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
On Fri, Nov 04, 2005 at 01:16:31PM +0100, Frank K?ster wrote: What do the security people mean with per-user temp directories? It's clear that $HOME/tmp would be bad, but /tmp/$USERNAME/ with proper permissions doesn't sound so awkward. Sorry for not being more clear. The default (only?) behavior of libpam_tmpdir is to set $TMP and $TMPDIR to /tmp/user/$UID. noah signature.asc Description: Digital signature
Re: per-user temp directories by default?
On Fri, Nov 04, 2005 at 01:00:48PM +0100, Klaus Ethgen wrote: That whould be no good idea for security environment where you do special think to secure /tmp (make it in memory and encrypt swap). With tempdir in users home all applications like for example gpg write temporary files to this location which ends up unencrypted on a disk or, more bad over an unsecure NFS share to the fileserver. Please don't do this by default as it break the security of many, many systems! First of all, libpam_tmpdir doesn't put $TMP in $HOME. Second, we're talking about the *default* configuration. If you're doing something with encrypted swap or $HOME on NFS, you've already diverged quite a bit from the default configuration, so your security would not be broken even if $TMP was in $HOME. You'd simply have one single line to delete from the default pam configuration. noah signature.asc Description: Digital signature
Re: per-user temp directories by default?
On Fri, Nov 04, 2005 at 08:12:39AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote: There are a number of outstanding insecure tempfile vulnerabilities, and there has been some talk that they're both too numerous and of low enough impact that they're not even worth releasing DSAs for. Never the Where was that talk done? I've been the one auditing that and there have been DSAs for most of the bugs I've reported to the audit team. Granted, they are not being issued inmediately (I usually provide the report and a patch), but they are on the queue as far as I know. Yes, your numerous reports are what lead to this discussion, which happened within [EMAIL PROTECTED] Basically somebody was like whoa, we'll never be able to fix all of these! And why should we, anyway, since the problems are so minor? So it was proposed to at least provide an additional layer of safety so we can say that this class of bugs generally does not affect our default configuration. The problem is, there's lots of those. And when I mean lots I mean that I have a list of ~4780 binary packages of which at least ~2300 make use of insecure tempfiles for sure and the others need to be reviewed (as the script So can we really be expected to release ~2300 DSAs to fix all these things? Even with patches to fix them, it's going to be an insane amount of work. This is exactly why we want libpam_tmpdir. IMHO, it's a worthwhile goal for etch but it should be done at the same time that there is a policy change mandating the use of mktemp/tempfile for shell scripts, File::Temp in perl scripts, tempnam in Php, tmpfile in C and safe constructs in those languages that lack a proper implementation (see #291389, for example). You may be right that a policy change would be required. Packages would need to respect $TMP or $TMPDIR in order for this proposal to work. As has been pointed out earlier (Joey Hess mentioned CUPS breaking), this may result in a number of bugs. noah signature.asc Description: Digital signature
Re: per-user temp directories by default?
Re: Noah Meyerhans in [EMAIL PROTECTED] Sorry for not being more clear. The default (only?) behavior of libpam_tmpdir is to set $TMP and $TMPDIR to /tmp/user/$UID. The only difficult point I can see is that (the same) $TMPDIR should also be available in chroots. I bind-mount /tmp in my chroots; if libpam_tmpdir would create a new directory there, that would be bad as files and sockets should be shared among the host and chroot filesystem. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: per-user temp directories by default?
On Fri, 4 Nov 2005, Lars Wirzenius wrote: I don't think the suggestion was to make TMP=~/tmp, but TMP=/tmp/$USER, where /tmp/$USER is owned by the user in question and is inaccessible to others. It would be a lot better to use TMP=/tmp/users/$USER, as user names are pretty likely to clash with files already in /tmp. You can't pre-create all user dirs at boot as well -- there may be hundreds of thousands of users, new users can be created on the fly, or perhaps an authenthication mechanism doesn't even support providing you with the list of users. Having a non-world-writable directory that can be written to only by a pam module which then chowns the individual dirs it creates would prevent such clashes. Regards, -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
On Fri, Nov 04, 2005 at 09:51:19AM -0500, Noah Meyerhans wrote:
Where was that talk done? I've been the one auditing that and there have
been
DSAs for most of the bugs I've reported to the audit team. Granted, they are
not being issued inmediately (I usually provide the report and a patch), but
they are on the queue as far as I know.
Yes, your numerous reports are what lead to this discussion, which
happened within [EMAIL PROTECTED] Basically somebody was like whoa, we'll
never be able to fix all of these! And why should we, anyway, since the
problems are so minor? So it was proposed to at least provide an
additional layer of safety so we can say that this class of bugs
generally does not affect our default configuration.
The problem is, there are some issues which are *not* minor. Packages
that hardcode /tmp are either, from my experience:
- old stuff that was written when /tmp/something.$$ was believed random
enough and safe. Easily fixed with a proper patch.
- new stuff that has been coded in a sloppy way, reviewing that code usually
brings up a lot of other security bugs.
Sometimes, the /tmp bugs are more serious that one might believe at first
sight because:
a) they are predictable, i.e. a cron task runs the code or a daemon does it
periodically. For an example, see #256381
b) the code is run as root, not as $RANDOM user. For an example, see #249616
It's even worst if a) and b) happen together, for example see #256377, or
#329384. Those kind of bugs should have a DSA, they are not minor bugs.
The problem is, there's lots of those. And when I mean lots I mean that I
have a list of ~4780 binary packages of which at least ~2300 make use of
insecure tempfiles for sure and the others need to be reviewed (as the
script
So can we really be expected to release ~2300 DSAs to fix all these
things? Even with patches to fix them, it's going to be an insane
amount of work. This is exactly why we want libpam_tmpdir.
You will have to, regardless of libpam_tmpdir. As I've said, those have
hardcoded /tmp paths in them so libpam_tmpdir will not prevent the attack.
From what I've seen, those that make use of TMPDIR (either explicitly or
because they use 'mktemp -d' or 'tempfile') seldom have race conditions.
IMHO, the use of $TMP or $TMPDIR should be mandated first in order for the
introduction of libpam_tmpdir to be really effective.
You may be right that a policy change would be required. Packages would
need to respect $TMP or $TMPDIR in order for this proposal to work. As
has been pointed out earlier (Joey Hess mentioned CUPS breaking), this
may result in a number of bugs.
A number is an understimation. There's lots of programs out there with
hardcoded /tmp stuff that are _not_ vulnerable to symlink attacks which would
need to be found and fixed.
A final point for consideration: libpam_tmpdir is not going to drive symlink
attacks through temporary files away. There are packages that use temporary
directories but are _not_ tmp. Some examples: the system's /var/lock/ and
/dev/shm/, php4'as /var/lib/php4 (see #257111 for some discussion about
this), php5's /var/lib/php5, transcriber's /var/lib/transcriber/ (fixed, see
#257112), apache-common's /var/lib/apache/mod-bandwidth/ (see #257108, which
was fixed with a simple note in the README.Debian file), tetex-base's
/var/cache/fonts/{pk,source,tfm} and /var/spool/texmf/{pk,source,tfm}. All
those are possible targets for security vulnerabilities for the programs that
use them and will not be covered by the introduction of libpam_tmpdir.
Regards
Javier
signature.asc
Description: Digital signature
Re: per-user temp directories by default?
On Fri, 4 Nov 2005 01:42:08 -0500, Joey Hess [EMAIL PROTECTED] said: One problem I have experienced is that if I manually start cups via its init script, as root, the cups daemon ends up running as a less privliged user that cannot write to /root/tmp, and the failure mode is quite horrible (silent failure to print anything). This could possibly be fixed by having programs fall back on a hardcoded /tmp if $TMP is not writable. And/or by having init scripts clean up their environment. And of course I would consider silent failure to be a bug in CUPS. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
On Fri, Nov 04, 2005 at 06:21:09PM +0100, Javier Fernández-Sanguino Peña wrote:
A final point for consideration: libpam_tmpdir is not going to drive symlink
attacks through temporary files away. There are packages that use temporary
directories but are _not_ tmp. Some examples: the system's /var/lock/ and
/dev/shm/, php4'as /var/lib/php4 (see #257111 for some discussion about
this), php5's /var/lib/php5, transcriber's /var/lib/transcriber/ (fixed, see
#257112), apache-common's /var/lib/apache/mod-bandwidth/ (see #257108, which
was fixed with a simple note in the README.Debian file), tetex-base's
/var/cache/fonts/{pk,source,tfm} and /var/spool/texmf/{pk,source,tfm}. All
those are possible targets for security vulnerabilities for the programs that
use them and will not be covered by the introduction of libpam_tmpdir.
Please explain what attack vector you see for /var/lib/php4. The semantics
for /var/lib/php4 were chosen very carefully to specifically *avoid*
security problems, and you made no mention in #257111 of specific attack
vectors that you were concerned about. The only attack vector I can foresee
here would be a brute force attack to guess the names of session files
located within the directory, which is unavoidable without moving to
per-uid session directories by default (which then doesn't meet the needs of
sites that share session files across security contexts).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: per-user temp directories by default?
On Thu, 3 Nov 2005 23:16:43 -0500, Noah Meyerhans [EMAIL PROTECTED] said: Within the security team, there has recently been some talk of pushing for per-user temp directories by default in etch. I'd like to see what people's reaction to such a proposal would be. session optional pam_tmpdir.so I have little operational experience with this PAM module, though. Does it cause problems for certain apps? If so, could these problems be solved with a less simplistic PAM configuration? It may need some tweaking of SELinux policy, depending on where these per user temporary directories end up in. manoj -- An ounce of mother is worth a ton of priest. Spanish proverb Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
per-user temp directories by default?
Within the security team, there has recently been some talk of pushing for per-user temp directories by default in etch. I'd like to see what people's reaction to such a proposal would be. There are a number of outstanding insecure tempfile vulnerabilities, and there has been some talk that they're both too numerous and of low enough impact that they're not even worth releasing DSAs for. Never the less, they are potentially dangerous and should be dealt with on some level. We believe that using libpam_tmpdir by default should make nearly all of these vulnerabilities cease to be relevant (there are some braindead apps that have /tmp hardcoded and don't use $TMP or $TMPDIR). As far as I can tell, we would simply need to move libpam-tmpdir from priority optional to required and modify the default /etc/pam.d/common-session to include the following line: session optionalpam_tmpdir.so I have little operational experience with this PAM module, though. Does it cause problems for certain apps? If so, could these problems be solved with a less simplistic PAM configuration? noah signature.asc Description: Digital signature
Re: per-user temp directories by default?
On Thu, 3 Nov 2005 23:16:43 -0500, Noah Meyerhans [EMAIL PROTECTED] said: [...] session optional pam_tmpdir.so I have little operational experience with this PAM module, though. Does it cause problems for certain apps? If so, could these problems be solved with a less simplistic PAM configuration? I've been using it for quite a while, and pretty much all applications work fine (although, as you mentioned, some applications hardcode /tmp). The only problems, I think, that I have come across are when two programs try to communicate over a named pipe, or shared file, and one of them hardcodes /tmp, and the other uses $TMP. I don't remember which programs did that, but I remember it happened at least once. Another potential problem is if a run a suid (non-root) program that attempts to create a file in $TMP. But it's suid, so it doesn't run under my uid, and doesn't have permissions to write to $TMP. But I've never run across that -- suid programs are pretty uncommon. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
Hubert Chan wrote: Another potential problem is if a run a suid (non-root) program that attempts to create a file in $TMP. But it's suid, so it doesn't run under my uid, and doesn't have permissions to write to $TMP. But I've never run across that -- suid programs are pretty uncommon. I don't use pam_tmpdir, but all my user accounts do have their own ~/tmp directories and I use $TMP (and TMPDIR) to make programs use them. One problem I have experienced is that if I manually start cups via its init script, as root, the cups daemon ends up running as a less privliged user that cannot write to /root/tmp, and the failure mode is quite horrible (silent failure to print anything). -- see shy jo signature.asc Description: Digital signature
Re: per-user temp directories by default?
On Thu, Nov 03, 2005 at 11:16:43PM -0500, Noah Meyerhans wrote: There are a number of outstanding insecure tempfile vulnerabilities, and there has been some talk that they're both too numerous and of low enough impact that they're not even worth releasing DSAs for. Never the Where was that talk done? I've been the one auditing that and there have been DSAs for most of the bugs I've reported to the audit team. Granted, they are not being issued inmediately (I usually provide the report and a patch), but they are on the queue as far as I know. less, they are potentially dangerous and should be dealt with on some level. We believe that using libpam_tmpdir by default should make nearly all of these vulnerabilities cease to be relevant (there are some braindead apps that have /tmp hardcoded and don't use $TMP or $TMPDIR). The problem is, there's lots of those. And when I mean lots I mean that I have a list of ~4780 binary packages of which at least ~2300 make use of insecure tempfiles for sure and the others need to be reviewed (as the script I use produces false positives and false negatives). And that doesn't include the source packages that use /tmp insecurely (i.e. when building a package). I have focused fixing the issue in the most popular packages (stuff like mozilla, mysql, lm-sensors, lintian, lilo, cfengine, to name a few) and I'm producing patches for the rest as time permits. There's even scripts that use 'mktemp' but don't use the -t option so they are rooted in /tmp nevertheless (notice that 'tempfile' does this by default). And there are even some packages which do _not_ have insecure tempfile vulnerabilities but hardcode the directory or file location to /tmp in any case. IMHO, it's a worthwhile goal for etch but it should be done at the same time that there is a policy change mandating the use of mktemp/tempfile for shell scripts, File::Temp in perl scripts, tempnam in Php, tmpfile in C and safe constructs in those languages that lack a proper implementation (see #291389, for example). Regards Javier signature.asc Description: Digital signature
