From owner-freebsd-security Wed Jun 7 20: 7: 4 2000 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 1E2F037B8AC for ; Wed, 7 Jun 2000 20:06:59 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id UAA24898; Wed, 7 Jun 2000 20:06:50 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda24896; Wed Jun 7 20:06:46 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id UAA00954; Wed, 7 Jun 2000 20:06:46 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdwGl952; Wed Jun 7 20:06:17 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.1/8.9.1) id e5836GM02334; Wed, 7 Jun 2000 20:06:16 -0700 (PDT) Message-Id: <200006080306.e5836GM02334@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdkd2330; Wed Jun 7 20:05:32 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cy To: Bengt Richter Cc: Cy Schubert - ITSD Open Systems Group , freebsd-security@FreeBSD.ORG Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug) In-reply-to: Your message of "Wed, 07 Jun 2000 18:35:56 PDT." <3.0.5.32.20000607183556.00908730@mail.accessone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Jun 2000 20:05:32 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <3.0.5.32.20000607183556.00908730@mail.accessone.com>, Bengt Richter writes: > 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. Except that $HOME is not understood in the kernel. This would overly complicate the kernel. A simpler approach would be to have a /tmp address space that would be addressable by any process with the same UID. When the last process belonging to a UID terminates, the UID's /tmp address space would be freed, deleting any files in the UID's /tmp. Only the UID and root would have access to the UID's /tmp. Root would have access via a portal-like filesystem that would map all users /tmp filesystems. Rather than having the kernel manage this new filesystem, have an automounter-like process manage the filesystem. This way the filesystem could be mapped to a users subdirectory implementing the policy outlined above and making the auto cleanup discussed above optional. Rather than implementing the policy I outlined above this same daemon could be used to implement the policy you outlined. The beauty of this is that flexible, even individualised policy definition and complexity would now be external to the kernel, using the same kernel interface that amd uses. We have a base of code to start with too: amd. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message