Slashdot Mirror
OpenBSD 3.2 Readies For Release, pf Matures
An anonymous reader writes "Just over a year ago, OpenBSD creator Theo de Raadt ripped ipfilter out of the OpenBSD code leaving "the world's most secure OS" temporarily without a packet filter. Here's an interesting interview with Daniel Hartmeier, author of pf, the stateful packet filter developed as a replacement. Now just over a year old, it sounds like pf has already become a serious contendor in the world of stateful packet filtering. This interview is of particular relevance with OpenBSD 3.2 to be released on Friday, 11/1."
Does anyone know if anyone has ported the OpenBSD pf over to Debian?
What I don't get is why don't these projects realize the kind of coup they could score by releasing a Mandrake/RedHatesque installer that even the average marketting drone could use to setup a fully operational installation. I'd love to use OpenBSD if I thought I could get it working. I'm still just a novice with *NIX though so some of this is a bit too hardcore for people like me right now. But still, getting OpenBSD an installer that **just works** for the average person would take it to a whole new level.
A lot of very high end stuff runs on systems with distributed administration (like most of America's transaction processing, accounting, etc...) Back in the late 70's - early 80's capability systems were a huge percentage of the market.
You don't need a file system to have data -- for an example you are likely familiar with think of palm OS. Data is just stored in internal program specific data structures and "swapped" out of ram to disk. The important thing is that the disk is just a bunch of sectors with a zillion different data formats; but to understand the organization of the date requires running the system which imposes the security model...
but to understand the organization of the date requires running the system which imposes the security model.
NO, that would simply be security through obscurity which does not work. Any modern capabilities based OS would have strong cryptography at its core so that you could not access those data items that you do not have a key to. In fact a cool way to do it (not sure if this is done in any real system) would be to have 2 keys, one for the runlevel and one your private key which is protected by your login, that way you could not access things outside your runlevel and you could not access other data in your runlevel unless it was explicitly given permission to you by using your public key (think ACL's but the creator of the data would have to add your key to the files encryption)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
I don't know about Z-OS, but I've read a little about EROS. EROS doesn't need a filesystem. That's because everything in EROS is persistent. The system saves a complete snapshot of its virtual memory to disk every couple of minutes. There is no "rebooting" of the OS. If you pull the plug, it comes back up exactly in the state of the last snapshot.
For me, it took a little while for that concept to sink in. They're saying that there's no need to redundantly keep information in permanent storage and volatile storage. Just make it all permanent, and you don't need the filesystem concept at all. In one step, you eliminate whole classes of bugs (parsing, file permissions, sharing files, filesystem namespace problems, etc.)
Their authority model also makes sense. Think of your system as a large building. Normal OSes treat security like doors with electronic badge readers; you're allowed to do things based on who you are. Naturally, a lot of doors must be programmed to let you through if you're going to get around the building to do your work. It's hard to ensure that each person is never able to get into a room that they shouldn't be in.
EROS is more like a building full of unique old-fashioned key locks. You have no automatic authority to go through any door. You must obtain the individual key for each door. You get these keys on an as-needed by the people in various rooms you interact with as you do your work. Each person with keys to hand out individually determines if you are worthy to go through the next door.
Reading up on EROS really expanded my view of how an OS could work. You can check it out at www.eros-os.org.
(Yes I know this is offtopic) Speaking of which, does anyone know why the US uses MM/DD and everywhere else uses DD/MM? And please don't use the typical "Because USians give a rats ass about the rest of the world" (even though its true)
Do not go gentle into that good night. Rage, rage against the dying of the light.
You are missing all the bugs that might be in the code still running as uid 0. Your daemons, the kernel, all of them are vulnerable. I haven't seen many exploits that actually get root by doing "su" to it, so "disabling" that account will not achieve more than, for example, a good password.
A "secure" OS in this context means an OS with well-known "clean", stable code that has been reviewed for flaws etc etc. There isn't much you can do from an administration point of view if the services/daemons you have to use are flawed.
I think sprinkling setuids around is not a great idea at all. Especially custom-written ones. Beautiful things can happen accidentally linking against the wrong library in a chrooted dir :)
Chroot is *not* 100% secure. It is not a sandbox. You can still access ports, memory and processes and kernel functions, you can talk to daemons, starve the system of resources or convince the parent process to do things it will regret.
Plus if you chroot users you'd still have to give them most of the OS somewhere unless they login to not do any work, and that will soon get boring when you'll have to upgrade all of it.
A truly secure machine requires hardware support. A better CPU design. If the 8086 did not mix stack with code and data we would not have had so many problems today.