Date: Thu, 20 Jan 2000 13:45:41 -0500 From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: Andriss <andriss@andriss.com> Cc: questions@FreeBSD.ORG Subject: Re: suggestion to prevent /tmp races Message-ID: <20000120134541.B72914@cc942873-a.ewndsr1.nj.home.com> In-Reply-To: <Pine.BSF.4.21.0001201118020.75919-100000@netmint.com>; from andriss@andriss.com on Thu, Jan 20, 2000 at 11:23:49AM -0500 References: <Pine.BSF.4.21.0001201118020.75919-100000@netmint.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 20, 2000 at 11:23:49AM -0500, Andriss wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > Hello, > > After reading the latest advisory on the make -j /tmp race I decided > to post to the list a suggestion that could theoretically prevent or > make significantly harder the /tmp races... > > For example, if you set the following permissions on /tmp: > > drwxrwx-wt 3 root wheel 512 Jan 20 11:17 tmp > > ... no ordinary users will be able to list the directory, but they > can list (and fully use) their own files if they know what the file > name is. Now, users don't have to list the directory at all! > They just have to be able to create the files, and use them. > > 99% of the time, it's some program that creates that files for the > user, for instance Pine. Not being able to list the directory would > not break this behaviour.. > > A similar suggestion could also apply to vi.recover.. Security through obscurity. This does not solve the race condition. It just gives the victim more of a head start. The attacker needs to now make guesses at the file name created. For many programs it is fixed (e.g. <string>.<pid>) so he might not even need to guess. For others it is typically <string>_XXXX where 'XXXX' is "random" characters. An attacker can make a lot of guesses and cover most or all of the namespace. A better method is for a user to make a 700 permission directory in /tmp, although there are still some details to making even that secure. -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000120134541.B72914>