Date: Thu, 17 Jun 1999 06:06:10 -0700 From: "Richard Childers" <rchilders@hamquist.com> To: "Bruce Campbell" <bc@thehub.com.au> Cc: <security@FreeBSD.ORG> Subject: Re: some nice advice.... Message-ID: <3768F2C2.B8C340BB@hamquist.com> References: <Pine.BSF.3.96.990617092943.1559i-100000@zerlargal.humbug.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
"Cue burning your own bootable CD and booting from that." I've been wondering when this would happen, myself, also. It seems to me that CDs have been fast enough for quite a while; regrettably, as devices get faster and faster, peoples' expectations seem to get higher and higher. I have speculated about building a system with a vast amount of RAM, setting the sticky bit on selected executables to make them memory-resident, moving the operating system to a bootable CDROM and making everything that needs to be writeable in /var, which, of course, would be a normal read-write magnetic drive. I don't mind saying that I was really excited to see that Nokia's IP400 firewalls (which run a derivative of FreeBSD, BTW) have their filesystems arranged in precisely this fashion; regrettably, this is only so that those filesystems can be mounted read-only; the only filesystem which is mounted read-write is /var, much as was described in the previous paragraph. It may be speculated that the engineer(s) whom came up with this rearrangement of filesystem mount permissions (and the slight changes to administrative files in /etc which needed to be moved to /var/etc) were intending to implement precisely this arrangement of devices (bootable CDROM, that is) ... and that this plan was interrupted when Ipsilon (the company that was developing the Ipsilon IP400 series of firewalls) was purchased by Nokia - which marketed the devices as was. Or maybe they just haven't thought about sticky bits and are driven by considerations of speed of response. (-: Whatever the case, Nokia's implementation of the FreeBSD paradigm is poised to move into this niche when the conditions are right for it to happen; perhaps others better informed as to the low-level issues related to device response time might care to summarize why no one has done this yet. My discussions with peers indicate that this seems like a perfectly good product, lacking only someone funded or otherwise organized to achieve this goal; it occurs to me that the FreeBSD organization itself might wish to undertake such an option, as an extension to already existing hooks for operation as a firewall. (In compliance with the GNU-derived licensing requirements, Nokia has published certain elements of their code; I'm not sure what, exactly, perhaps it is no more than the devices drivers used for the 4-port, 100mbps ethernet, and other devices; but I think I forwarded this URL to JKH last December, for his information; if there is interest, I can dig it up again. Nokia's URL is http://www.iprg.nokia.com .) -- richard Bruce Campbell wrote: > > On Wed, 16 Jun 1999, Warner Losh wrote: > > > In message <Pine.LNX.3.96.990616182221.28882A-100000@static-petef.netreach.net> Pete Fritchman writes: > > : If you get compromised, why does it matter? > > : The attacker compiles a new kernel, waits for you to reboot, boom. > > > > Nope. My kernel is set schg and i run at a high secure level so you > > can't replace my kernel. > > Cue burning your own bootable CD and booting from that. > > --==-- > Bruce. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3768F2C2.B8C340BB>