From owner-freebsd-security Thu Jun 8 23:59:45 2000 Delivered-To: freebsd-security@freebsd.org Received: from berlin.axl.net (berlin.axl.net [216.66.11.23]) by hub.freebsd.org (Postfix) with SMTP id 36DCF37C232 for ; Thu, 8 Jun 2000 23:59:42 -0700 (PDT) (envelope-from matt@axl.net) Received: (qmail 42148 invoked by uid 85); 9 Jun 2000 07:04:47 -0000 Received: from matt@axl.net by berlin.axl.net with scan4virus-0.19 (sweep: 1.8/3.33. . Clean. Processed in 0.63168 secs); 09/06/2000 07:04:46 Received: from ws-01.matthennigus.lightningdsl.net (HELO sinister) (216.66.30.66) by berlin.axl.net with SMTP; 9 Jun 2000 07:04:46 -0000 From: "Matthew B. Henniges" To: Subject: RE: FreeBSDDEATH.c.txt (mmap dirty page no check bug) Date: Fri, 9 Jun 2000 03:03:02 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3.0.5.32.20000607183556.00908730@mail.accessone.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org And what of suid programs? Do they use the users tmp(and possible fall to symlink/race/whatever..) or do they use a different one(roots?) do suid programs all use roots /tmp, no matter who runs them? Matthew B. Henniges CoPresident Axl.net Communications http://www.axl.net (203) 552-1714 > -----Original Message----- > From: owner-freebsd-security@FreeBSD.ORG > [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of Bengt Richter > Sent: Wednesday, June 07, 2000 9:36 PM > To: Cy Schubert - ITSD Open Systems Group > Cc: freebsd-security@FreeBSD.ORG > Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug) > > > At 06:11 2000-06-07 -0700 Cy Schubert - ITSD Open Systems Group wrote: > [...] > > > >Replacement candidates for /tmp and /var/tmp are: > > > >1. Each user has a subdirectory in /tmp as /tmp/$USER. An idea brought > > forth to BUGTRAQ by Theo de Raadt of the OpenBSD project. > > > >2. Each user maintains their own /tmp as $HOME/tmp or some such thing. > > An idea I had discussed with my co-workers a number of years ago. > > > > I have an inkling of a third way, for backwards compatibility with #2. > Suppose you create a pseudo-device (/dev/home ?) whose only purpose is > to support a pseudo-file-system, whose only purpose is to return > $USER-dependent symbolic links? (A new kind of symbolic link might > be more efficient, but I'm looking for a way to do it within current > mechanisms). /dev/home/xxx would be mounted at /yyy to get the effect of > opening /yyy/file to be opening $HOME/xxx/file. For our case, use tmp for > both xxx and yyy. That's the sketch, anyway. > > The above deals with (hidden) partitioning of the /tmp namespace, but does > not address the hint-carrying aspect of "tmp." As other posts > have mentioned, > "tmp" might mean: > a. You want a fast small scratch file > b. It might not be small > c. You want garbage collection service > d. Access may be very public, so think twice > Other usage hints might be: > e. You want sequential read-only access with huge read-ahead > buffering for a jitter-glitch-free multimedia stream > f. You want a no-persistent-cleartext-guaranteed file > > You can easily expand on this, but my point is that maybe > namespace, access > control, and performance tuning goals should be separated (at least for > discussion purposes ;-) so that if there is going to be changes, solutions > will be implemented in appropriate contexts. > > One way of specifying something about a file is by saying it > applies to all > files in a particular namespace (or subspace: e.g., leading dot, trailing > .vbs :) > or directory. Another is to mark the files with attribute flags or ACLs. > Another is to pass arguments to access functions like open(), or > ioctl(), etc. > Another is to wrap it in some new object. Etc., etc. If we don't identify > what we're doing, and the options, we won't think about them > until a legacy > pinches. > HTH. > > Regards, > Bengt Richter > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message