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.
- broken drivers stolen from other BSD
... Sure, you hit the nail on the head, yeah that's it! What, Sigmund Freud to the rescue.
- no RX polling for network drivers. Linux and FreeBSD have this. I'm sorry if you don't know what RX polling is for, but it is to prevent livelock in an interrupt driven kernel.
- no SMP. I would venture to guess that that's considerably more difficult that "auditing" (snicker) code. Its always easier to complaint than create, something Theo has mastered.
- no reasonable way of updating the OS. Solaris has it. RedHat has it. Even Microsoft has it. Theo's way, buy a new CD, or compile the patches yourself in a way which is not extensible. Smart.
I would never, ever use this in production. If you think I'm a Slashbot, all I have to say is.
Just a note to you idiots out there, Juniper uses FreeBSD for their JuneOS on some very high end equipment. The engineers would probably urinate themselves laughing if you suggested putting OpenBSD on an M160. Oh, don't know what Juniper or an M160 is? That's what I thought.
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.
- no SMP - because no one who is smart enough to deal with SMP kernels would ever tolerate Theo de Raadt.
- check out the fxp driver. If you can't tell they rip and port, you must be incapable of reading. Funny also that the fxp driver on FreeBSD supports polling. Funny also that FreeBSD cleanly supports more hardware and oh gee, APIC on UP boxes!
- no response to the RX polling. FreeBSD's polling implementations was by the Xorp ROUTER project. I have also performed throughput tests with OpenBSD. Trust me, at gigabit line speeds you either need to poll or have lots of CPU to deal with ingress packets - especially if the packet size is small. Show what you know about performance. Nothing.
- cvsup would be nice, more efficient.. Or binary packages for the server things like root exploits in SSH. People with jobs don't have time to compile things. OpenBSD is just behind the times. Painfully so.
So SMP not needed up there for border devices (yeah, right, that why GSR routers and every other router worth its salt use network processors dedicated for every interface)? So if a machine doesn't have a network processor for each interface, how exactly then is a uni-processor OpenBSD box without polling going to deal with 6 gigabit cards? Interesting. You don't know. The FreeBSD in Juniper was a convenient and effective way for Juniper to have a full, coherent well documented BSD implementation professionally done.
I love people, zealots, who try and defend OpenBSD but they cant even get SMP working. Real kernel hackers probably snicker and giggle about Theo de Ass, but Linus and other k-hackers are just too polite.
And please, man, for the love of god. Please stop considering a good box to put in front of a 1.5mbps link a good networking box. You sound like a fucking fool.
BTW, in lab tests, OpenBSD is fairly trivial to DOS, without RX polling, ingress packets always generate interrupts even if they get dropped by filters. No CPU left or userland = livelock. Oh! Wait, you've *never* tested these kind of things because you are either unemployed or worthless to your company [poor company to have to put up with you].
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.