OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)
From: Cy Schubert - ITSD Open Systems Group (Cy.Schubertuumail.gov.bc.ca)
Date: Wed Jun 07 2000 - 22:05:32 CDT

In message <3.0.5.32.20000607183556.00908730mail.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.Schubertosg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message