|
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: John Brazel (john
tellurian.com.au)Date: Wed Jun 07 2000 - 01:07:04 CDT
- Next message: Matthew Dillon: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- Previous message: Cy Schubert - ITSD Open Systems Group: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- In reply to: Cy Schubert - ITSD Open Systems Group: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- Next in thread: Cy Schubert - ITSD Open Systems Group: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- Next in thread: Matthew Dillon: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- Reply: John Brazel: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- Reply: Cy Schubert - ITSD Open Systems Group: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> >From a security standpoint a shared temporary filesystem coupled with
> applications written as they are can be an invitation for compromise.
> Suggestions ranging from no temporary filesystem at all to
> subdirectories in /tmp for each user have been discussed on
> FreeBSD-security and BUGTRAQ for many years. Of course for root
> /var/run reduces the risk. The concept of a virtual temporary
> filesystem for each user, e.g. /tmp as and address space addressable by
> a single process group and only sharable by that process group or even
> a single process, might go a long way to mitigate some of the risk.
What exactly ARE all the risks? At the risk of 'over-enthusiasm'
(for want of a better phrase), would a purpose-written,
security-oriented filesystem solve it?
Something like /tmp, but with an embedded sticky bit (permanently
set) and the inability to create symlinks (the symlink(2) syscall
would return ENOSYS for that filesystem).
The question, of course, is, would this fix enough of the problems
to warrant all the effort? At the very least, backward compatibility
wouldn't be affected.
J.
To Unsubscribe: send mail to majordomo
FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
- Next message: Matthew Dillon: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- Previous message: Cy Schubert - ITSD Open Systems Group: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- In reply to: Cy Schubert - ITSD Open Systems Group: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- Next in thread: Cy Schubert - ITSD Open Systems Group: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- Next in thread: Matthew Dillon: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- Reply: John Brazel: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- Reply: Cy Schubert - ITSD Open Systems Group: "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]