OpenBSD 2.7 Released
dragonfly_blue writes: "Just wanted to let you know, OpenBSD 2.7 is out, with significant advances; including OpenSSH2, better Linux binary emulation, DSA encryption, and (my personal favorite) support for encrypting your swap space. Theo and the gang have also expanded the ports and packages collections considerably, so get 'em while they're hot!"
(More.)
ocipio contributed some more tidbits, writing: " ... OpenBSD 2.7 improves support for high end system boards, SCSI controllers, ethernet interfaces, and adds gigabit ethernet drivers and IPv6 networking. OpenBSD's cryptography has been further enhanced by encrypting virtual memory swap space, and by more flexible ISAKMPD key exchange and operating modes for IP Security networking." To keep things interesting in BSD Land, he adds "According to Jordan Hubbard, FreeBSD's release engineer, FreeBSD 3.5 will be released June 20th."
Cool on all counts. Way to go, BSD crew! (And Thanks! to everyone who pointed out this release.)
Sorry. I'm cranky. I have to write a program in its entirity before tomarrow morning. I mean to include the :), really I did.
A deep unwavering belief is a sure sign you're missing something...
No alpha port this time due to lack of support from users. Check out http://www.openbsd.org/want.html :
:)
"If we do not get some of these very soon, we are not going to ship OpenBSD/alpha on the 2.7 CD-ROM (it isn't worth our effort)."
Makes a lot of sense to me... unlike Linux distros and developers, who are backed by VC, IPOs, and cushy jobs, the OpenBSD team actually have to work for a living
jason
1. Theo's beef is with NetBSD, not FreeBSD.
2. If you don't wanna pay 25$ (miniscule), download it. Periodic CVS updates are recommended.
No. Do basic math: Swapping means at least 5 ms delay to throw data to disk, which is about as slow as anything can get. In these 5ms, you can encrypt quite a lot of data even with something as slow as DES. Blowfish would be blazingly fast.
In short: Encryption performance is about as fast as drive I/O, and initial delay on IO makes it unnoticeable.
Swap partition, no. Swap file, yes.. Encrypted loopback, or an encrypted filesystem holding said swap file..
Now this is off the cuff; This prolly won't work, and even if it did, it's be as slow as Windows95 on a 386.. But it is food for thought.. Ramdisk in memory, containing the 'swap space' mounted via a encrypted loopback. Make the ramdisk size close to physical, and you now have encrypted DRAM..
Or switch platforms; The AS/400, the S/80 and a variety of other IBM midranges are capable of it, even if they don't come out of the box that way..
.sig: Now legally binding!
Why stop there? Let's encrypt everything to the point of all we get on our screen will be a bunch of useless characters. We won't know what is going on, but the important part is neither will THEY! Encode our swap space, maybe that is exactly what they want us to do. Ever think about that?
This document makes a teensy error; it completely ignores the fact that the Linux swap space is not included in the Linux native file system; it has to be allocated on a separate partition with a different file system.
No, it doesn't ignore that; and no, it doesn't have to be on a seperate partition.
If you're not going to read the article, at least do a search for "swap" on it and read those lines.
Here's one for you from the article:
You will notice that I don't have a linux swap partition visible. My linux setup currently uses the OpenBSD swap area.
That's one way. Another is the use of a swap file on the Linux partition (or even on the BSD partition), which Linux can easily do.
How do you classify that as "ignoring" the question of swap space?
--
Without encrypted swap, an application with sensitive data may be swapped out at some point to the disk. Even if the process zeros its own memory eventually, this disk copy may be left around for prying eyes (another process does a large malloc and scans this dirty memory for keys/passwords).
It seems to me that zeroing the swap before reuse would be a cheaper alternative to this. Here is the argument for why I think encryption doesn't buy you any security that zeroing doesn't:
My reasoning is that another process would never get your old "dirty" memory with your key after a malloc. They would have to resort to spying in your memory in realtime.
As for someone looking at your actual memory in realtime, encrypted swap isn't going to stop that. If they are sufficiently powerful to do this, they are sufficiently powerful to go into the kernel, extract the swap encryption key and read things anyway.
Could someone more in the know explain what encryption buys you that kernel-level zeroing doesn't?
Sure, I'd be glad to explain. You're wondering why www.OpenBSD.org is running on a Solaris server. See this comment from the misc OpenBSD mail archive.
Basically www.OpenBSD.org runs on a University of Alberta server. The bandwidth is provided free. OpenBSD is looking for venture capital and funds are limited so why look a gift horse in the mouth?
While you're looking around the site, check out their T-shirts. I like the fish-cipher t-shirt t-shirt that any open source guy would like. It has the Blowfish code printed on the t-shirt's back.
Actually (ignoring the fact that your entire post is incorrect and filled with bogus information) OpenBSD is far more relevant than Solaris. Being operating systems, both are condemned to suck, but OpenBSD sucks far, far less. Solaris is slow, obsolete, and has more security holes than an unpatched Red Hat 5.0 [note to ignorant: that's a LOT]. OpenBSD is small, secure, and fast. If you're going to compare the relevance of OpenBSD, please compare it against that of a product with a future.
The Dallas Semiconductor 5002FP encrypts the address and data buses. It's an Intel 8051 compatible microprocessor, so forget about running Linux or *BSD.
Mea navis aericumbens anguillis abundat
Another process doing some malloc()s to see your ram isn't a problem - the kernel in this situation is going to zero the ram before that process gets to read from their malloc area, and in any case it won't have any reason to read in from untouched swap.
Generally speaking, while the system is running and permissions are set, there's not going to be any difference between encrypted and unencrypted swap security wise. Programs won't be allowed to read from swap space, and they aren't allowed to read each other's ram or core files, either (at least, not without permission). About the only case where encrypted swap would help while the system is running is if swap was, for some reason, mounted over a network connection or someone was able to otherwise sniff the channel between the system bus and the actual swap storage device. This might be an actual possibility if you were dealing with, say, some sort of thin client which didn't have a hard disk and swapped to the server, for instance. Secrets wouldn't be accidentally transmitted in the clear due to some app on the client being swapped out. I suppose encrypted swap might also be useful in keeping superuser attacks from extracting information which is no longer resident, but was in the past too, but if you have a root compromise, you're screwed anyway.
The real point of encrypted swap space is that it keeps your secret information from showing up in the swap file if someone steals your machine. Normally, the OS doesn't try to keep swap space clean, so whenever something is paged out, it'll just sit there in the swap partition until it gets overwritten. So, if someone stole your computer, they could then just scan through the memory dumps in your swap partition looking for secret data, and they might well find it. There's no way you could ensure that they wouldn't.
Various other methods to encryption, such as zeroing, aren't really going to help. There are a number of flaws to the zeroing idea:
- The swap space can only be zeroed when you actually release it. Thus, the OS would clear the swap block when it's no longer in use. This has the disadvantage of causing more disk IO, but more to the point, if the OS never sees the block get released, it never zeroes it out. So, the gestapo kicks down your door and rips the power cord out of the computer, the OS never gets a chance to clear itself out, and they get your secrets too. Bad.
- Zeroing the data won't necessarily erase it very well. Look at the wipe utility and all the hoops it has to go to in an attempt to securely erase data from your disk (and even then, it has flaws). It's very possible for someone to go over a swap partition that's been zeroed, and still recover data, even if it was erased a couple times.
So, basically, it's a lot better to guarantee that your secret is never written to disk at all in an unencrypted form, if you're really worried about it. That means, either you encrypt the swap file, which is a general solution, or you write your software so that, if it knows it has a secret, it will make sure the secret is never written to swap (for instance, by locking the secret in ram so it can't be paged out). The latter solution is good practice, but it's very hard to ensure it works properly.Well, im glad to see you like IRIX. (I like, and Use IRIX daily as well).
:)
As far as threading in irix, it didn't work with shit until 6.4. NFS on irix has been problematic at times, leading to pesky things like kernel panics, etc. The 32->64 bit migration on irix has been pretty amusing, unless you've actually had to use 3rd party tools or libs for anything, in which case, its been nightmarish. (n32 tools are better, vendiors love to ship o32... sound familiar ?)
IRIX has faults just like any other OS. I still like it. There is a pretty wide market niche for solaris to fill, one that IRIX wouldn't fill as well. Namely, Solaris has the right mix of "stable", "easy", and "thorough" to make it a very viable operating system. Outside of the world of slashdot, there are plenty of people that agree with me
IIRC, the largest IRIX installtion is ASCI-Blue mountain, at 6144 processsors. This is _not_ a single machine image. O2k machines have only been implemented upto 256 cpus with a single image, althoug the O2k architecture should support 4096 (see Lewis and Berg: Pthreads)
XFS _is_ a fast file-system. But if you were a hardcore irix user then you know its taken XFS a while to be what it is. Back in the day when we were running 5.3 + XFS, things were different. Back then there was no xfs_check. They just assumed it would alwasy work. This is in the XFS design papers, btw. Or like the time when XFS patches broke any possibility of conveniently booting a downed SGI machine (all the media was 6.2, effectivly patchlevel zero, but subsequent patches to the OS made the on-disk XFS file-system unreadable and thus unrepairable to the on-cd kernel and tools)
These sorts of things tend to not happen with solaris. It's not nearly as esoteric, so it doesn't have the bleeding edge performance of IRIX. On the other hand, it is very feature rich, and very stable as well.
Like i said, right mix of stabl, easy, and thorough. Might as well add "cheap".
My opinions are my own, and do not necessarily represent those of my employer.
Just curious, but what happened to the Alpha port? I noticed that all the previous versions included it, even bootable on the CD, but not 2.7. Any ideas? Theo overclock his Alpha and toast in in testing out the encrypted swap space or what?
-"Zow"
Its the "feds snatch the box" scenario. You do not want to create a record on disk of something that was decrypted, created before encryption, etc.
If sensitive data was written to the disk, it could be recovered even if written over (theoretically). This is protection for the extremely paranoid, but that is what OpenBSD is all about.
If you were booting with your root partition encrypted and all filesystems storing sensitive data encrypted, this is the final hole to plug to prevent anything unencrypted from being put on a disk unencrypted.
I see the danger as being what people are looking at when they take the disk from you, not what they can find when the system is running.
Of course. Proof that IRIX-targeting proprietary vendors are just as idiotic as Linux-targeting ones (libc5, yeah that'll make me buy your shit).
This is _not_ a single machine image. O2k machines have only been implemented upto 256 cpus with a single image, althoug the O2k architecture should support 4096
I'm familiar with the architecture. 256 is still four times as many as Sun offers. The Craylink technology used to link partial SGIs is also highly impressive. It's really a blazing-fast network, with hubs and so forth. Quite flexible.
These sorts of things tend to not happen with solaris. It's not nearly as esoteric, so it doesn't have the bleeding edge performance of IRIX.
IRIX 6.5, which has been around for quite a while really, is rock solid. I've had plenty of annoying problems with earlier versions, just like you. 6.2 and 6.3 would lock up, 6.1 was complete garbage, NFS had issues, and so on. But you have to compare equivalent systems - we're not comparing Solaris 2.8 with IRIX 6.2. Solaris versions less than 2.4 had a number of serious problems; it's generally conceded today that Solaris < 2.4 is effectively unusable. I'm not recommending that anyone use IRIX 5.3 any more than that they use Solaris 2.3. When comparing IRIX 6.5.[5-8] with Solaris 2.8, IOW contemporaneous operating systems, I think you'll find that IRIX comes out looking quite good for stability, ease of use, and feature set. Naturally YMMV but I'm disinclined to allow problems with earlier versions of IRIX to bew brought up in a comparison with more recent versions of (something else).
I get some mail from Theo (not to me personally, to the lists), and, although I'm not sure how long it will last, he is generally civil and forthcoming in them...
I don't know what to say about the packet filtering; is FreeBSD still filtering out packets from the OpenBSD networks, as they claim? "We won't stop filtering packets from the OpenBSD networks until Theo is out". Heh, it's fun to read archived threads sometimes.
Well, thanks for being honest; it's important for me to know how OpenBSD got its reputation. You seem like a good person, with very valid reasons for not using OpenBSD.
Free music from Jack Merlot.
This document makes a teensy error; it completely ignores the fact that the Linux swap space is not included in the Linux native file system; it has to be allocated on a separate partition with a different file system.
The Second Amendment Sisters
Finding God in a Dog
The other strong point in OpenBSD's favour is the code auditing process, but FreeBSD is now going along the same path of tightening up its codebase. Again, the distinctions between the two main BSDs are becoming blurred. If this continues, will there still be a need for OpenBSD? Given the history between Theo and the FreeBSD camp, I can't ever see the projects merging. And with the price differential between Open and Free (admittedly not much, but still significant) I think Theo may have to relinquish his stranglehold on the official ISO image to the distro if OpenBSD is to survive. Despite the advantages of OpenBSD, I am still put off by the prospect of paying $25 (?) every 6 months, when I can get FreeBSD for more-or-less the cost of distribution.
- Lita
I have OpenBSD 2.6 on a 486dx33 running in the kind of configuration you are looking for. I choose Open as that is what I had used before. Speed is a non-issue if you are just passing packets. Even my cheap ISA ne2000 cards can keep up with the cable modem. Even if you want to serve a few pages with apache or ftp a 486 is up to the task. If you want a system that you can install and forget, OpenBSD may be a better choice then FreeBSD. The 3 years without a remote exploit in the default install (which includes apache and sendmail) is comforting. I assume that FreeBSD can be secure as well, but they have always said that performance was their main concern whereas OpenBSD has always said that security is their main concern.
Compared to Linux I prefer OpenBSD as a gateway. I really like IPFilter and IPNat over IPchains. I find the configuration files much easier to read. For example the following blocks and logs all attempts to telnet to my gateway:
(The above is a quick'n'dirty example. Please consult the docs before making your own rules).IPFilter and IPNat do lack the proxies that come with Linux IP-MASQ. Generally this is not a problem as the IPFilter 'keep state' rule and IPNat seem to be smarter then Linux IP-MASQ. However I have not used Linux as a gateway for over a year so I could be wrong. If you IRC get the tircproxy package (look on freshmeat.net) and set it up as a tranparent proxy. Tircproxy proxies DCC connections and I recommend it to anyone using using IP-MASQ or *BSD IPNat
A good OpenBSD resource site is www.deadly.org
Too bad for them. I like IRIX. And BSD. And Linux, sometimes. Solaris, however, sucks my ass. IRIX has all the features you attribute to solaris, but it's actually fast. XFS is infinitely better than Solaris standard UFS, and you get it out of the box without paying extra. IRIX's thread implementation is functional, fast, and standards-compliant. NFS, including v3, works great. Intelligent SMP support? Well, IRIX runs on the 8k+-CPU nuke simulators and other massive Origin 2000 systems. Solaris can do 64 CPUs, but slowly (well, it can't do any number of CPUs quickly). I could go on, but I'm convinced the world is blind to Solaris's failings, which are many and severe.
The paper reference provided by an A-C above, http://www.citi.umich.edu/te chreports/citi-tr-00-3.pdf claims a 26% to 36% performance loss due to the swap space encryption in their benchmarks.
--
"You've crossed my Line of Death!" "What? No! Where is it?" "Here in the fine print...."
There is no Unix I know of where you get another processes' dirty memory when you malloc. When malloc first gets it's memory from the OS (with sbrk) it is zero'ed (I think in thery it is merely "not valid data", but in practice it is zero'ed). If you free that memory and malloc it again it might contain your own dirty data. Similar things happen with mmap'ing annon memory, and /dev/zero (the other way malloc is implmented nowadays). In Net and FreeBSD the free'ed memory is frequently madvis;ed as unused and will not be written to swap unless it is written to again (and will tend to come back as zero, unless it is written again).
When I say "no Unix I know of" this includes V7 (or V6 -- what is it the Lyon's book covers?).
Others have already said, but I'll state for completeness... If your system is seized by a hostle force (say your goverment, or it's a laptop, it could be a competeing bissness), the swap area could have cleartext passwords, or chunks of important documents. Of corse if you didn't encrypt your real data then there are other areas of intrest on the disk...
Your point is? WinDOS has almost 90% market share. Does that mean it doesn't suck? Solaris takes a beautifully-designed lightning-fast million dollar system and makes it run like a 386 with a flaky memory module. IMHO, that qualifies as "sucks." I guess your definition is different. Just remember me when you're trading up your expensive Sun box again to make up for the failings of Solaris; I'll buy the old system from you, put UltraLinux on it, and get the same performance you will at half the price. I wish BSD had SMP support, but it's still worth using if you have a UP system lying around. Linux on SMP UltraSPARC, however, is a thing of beauty.
Swap partition, no. Swap file, yes.
this ain't true: there's absolutely no problem using a loopback-ecrypted patition as swap-device.
Ramdisk in memory
absolutely pointless, since the encryption keys have to remain in (unencrypted) memory anyway.
I have the impression that some guy's miss the point here: encrypted partitions are not (primarily) meant to protect against intruders on a running system (a 2nd reason why encrypted ram is basically pointless) but to protect against theft, confiscation, seizuere (or whatever the legal pretext of the day may be called) of your hardware. It's about ensuring that once the power is turned off, there remains absolutely no recoverable data on the system.
Therefor it is, btw, reasonable to encrypt the swap partition with a random key transparently generated on startup (I've patched losetup to provide this very option.)
I have built an OpenBSD Firewall, and it has been chugging away on a $10.00 salvage 486 with two spare NICs for a few months now. OpenBSD uses the IPFilter packet filtering program for firewalling, and for Network Address Translation (having multiple machines share a single IP), you have IPNAT.
Both are included in the base install of OpenBSD, but need to be activated. From the OpenBSD FAQ at http://www.usa.openbsd.org/faq/faq6.ht ml#6.2 you can check out the IPFilter and IPNAT sections - this helped me to get running from practically step zero. The MAN pages in OpenBSD are also the best in the business, with example code and config files, and they are consistently getting better with each release.
To develop your rule base for IPFilter, you can't beat the IPFilter HOWTO located at http://www.obfuscation.org/ipf/. This has everything you need to know about creating a solid firewall without being an expert in TCP/IP packet routing.
So since you can get all the info for free, try downloading OpenBSD 2.7 and give it a shot. When it works for you WAY easier than you expected, take the cash that you would have spect on the firewall book and purchase the CD (and yes, mine is on the way...)
Good Luck and Enjoy!
True.... What we need are encrypted core dumps
encrpted swap is nice...but the big problem with memory is the core dump. If someone has local access to a box, and can get a core dump, there's a change they can get login-name/password-hash combo's, and it's trivial to run a word-list through a program like crack.
on improperly configured boxes, local access isn't even required as long as their running apache, because apache let's you enter the '..' directory in path names.
For IRC get tircproxy (look on freshmeat.net) and set it up as a transparent proxy. I would recommend this to Linux IP-MASQ users as well. I didn't bother with the oidentd part to tircproxy to set the usernames.
For ftp there is the 'proxy ftp' option for IPNat. I haven't really tested in though as my FTP client (lukemftp) is set to use passive by default. Netscape ftp seems to work though and I have no idea if it uses passive or not.
I feel compelled to agree with this comment. I too, must say that I really love Linux. That being said, it is _not_ a new user's operating system.
I feel that any of the *BSDs are very solid and production ready. I can't say that about a number of Linux machines. Linux can be made to be a very secure, wonderful, and easy Operating system, but for people wanting to get started, BSD is a better choice.
BSD's _biggest_ advantage is the weath of excellent documentation on general usage. OpenBSD's documentation is the man page system. Anything that you could possibly want to know about OpenBSD is in the man pages. This makes it very easy to find what you are looking for.
For those who also like "handbook" style docs, FreeBSD combines excellent man pages (sometimes Linux's manpages are a stretch) with a handbook that gives you a general overview of how to do basic administrative functions.
I advocate new users starting with FreeBSD because of the very user-friendly docs. FreeBSD's website has documentation that starts by teaching a user how to login! Seriously, read the "FreeBSD for people new to both FreeBSD and UNIX" documentation and tell me that wouldn't be good for _any_ new user.
OpenBSD is not quite so basic, but the docs are more friendly than anything I've seen from the Linux Documentation Project. I really like the LDP, but OpenBSD has some really great man pages.
If you are a linux user, check out one of the BSDs. You'll be glad you did. I started with Debian and Slackware circa kernel 1.2.13, and started using BSD last August. I'm hooked!
-Peter
. Penguins Surely Ca
Building Internet Firewalls, Second Edition Zwicky, Cooper, Chapman. This will provide you with more background information, but nothing on OpenBSD. (I was, not so much disappointed, as surprised, at this, for the first time with an O'Reilly book).
The best, in my very humble opinion, references are online, but they aren't as nice to read as the Building Linux and OpenBDS Firewalls book, but are an excellent suppliment.
http://coombs.anu.edu.au/ipfilter
http://www.obfuscation.org/ipf/
See the prior of the web pages for a mailing list (Majordomo). The author (Darren Reed) of IPFilter actively participates in this mailing list, which is helpful, and often appreciated.
Hope that helps
Brian
Actually, I didn't know NT had that feature. OpenBSD swap is only overwritten on demand, meaning the contents are not changed until that section of swap is overwritten as some process swaps into it..
There hasn't been any real 'zero'ing feature, save perhaps the paranoid individuals I have seen that include dd if=/dev/zero of=/dev/[swap] bs=1024 count=[swapsize] in their shutdown scripts..
.sig: Now legally binding!
Sounds like a Redh*t problem...but then you said you tried Debian, too. Back in the day, I started with SLS, then went to Slackware...nowadays, I'm using SuSE. (I took a quick detour into Corel Linux (based on Debian), but I couldn't get it dialed in just the way I wanted and didn't want to waste the time to figure it out when I knew how SuSE is configured.) I've installed SuSE on everything from a Cyrix 5x86 up to a K6-III and have never run into problems. I can't say that I've ever used Redh*t, but it seems that when someone posts to comp.os.linux.* or /. with a "Linux problem," it often ends up being a Redh*t problem.
I tried one of the BSDs (don't remember which one) a few years ago...there didn't seem to be anywhere near as much activity swirling around it as for Linux, so it didn't stay on my computer long. Now that my NetWare server setup is trashed (flaky i430VX-based motherboard, not a software problem...funny how most of the hardware problems I've run across have been with Chipzilla hardware, not stuff from this underdog or that underdog) and the machine it was on is fixed, maybe it's time for another trip into "BSD-land."
_/_
/ v \
(IIGS( Scott Alfter (remove Voyager's hull # to send mail)
\_^_/
20 January 2017: the End of an Error.
They grind code slowly but exceeding fine.
Seriously, it's a different philosophy with different priorities. Linux developers in general are more interested in rapid growth, a rapid release cycle, lots of feedback to fix stuff. BSD developers in general take a more "autocratic" (if you don't agree) or "controlled" (if you do) approach. And the OpenBSD team takes an "extraordinarily careful" approach, which is why we never hear about OpenBSD boxen getting cracked...
------
------
You are in a twisty little maze of open source licenses, all different.
I'm working my way through the Wiley book and finding it very good. There's a high-level (i.e. no code) overview of the various kinds of attacks and exposures, and what firewalls can (or not) do about each.
Then theres a, umm, diplomatic discussion of the choice parameters between using Linux or OpenBSD. It struck me as plain enough, between the lines, that they think OpenBSD has it all over Linux save in the level of support of some hardware, and possibly ease-of-install.
A fair bit of the book is devoted to the install of each, and configuration of the firewalls. I don't know if the book gives you anything about the actual setup that you can't get from OpenBSD's own documentation or the fine howto's at the "obfuscation" site, but I really benefitted from the textbook learning of the background of how IP packets work, and how lies inside them are the basis of most kinds of attacks.
PS: Good sense of humour in it, too. Buffer Overflow attacks are in a paragraph headed "Buffer: The IP Slayer".
I see OpenBSD has VLAN support. Very nice. Does anyone know when Linux will have this in the stock kernel? Linux or OpenBSD would be great as VLAN routers.
Any technology which is distinguishable from magic is not sufficiently advanced.
The /. community is mostly Linux-centric, the BSD section doesnt get a lot of readers (as opposed to other sections).
:)
A lot of people seem to have some misconceptions about OpenBSD vs. FreeBSD vs. Linux Distros. (I don't have a lot of experience with NetBSD)
OpenBSD's primary purpose in life is to provide the most secure operating system availible. I personally think it has succeeded very well in this respect. Its the only operating system I would ever let touch my servers. OpenBSD works alright as a workstation OS, but IMHO there are better choices, depending on your needs. It works great as a router or firewall, and with the inclusion of RTMX O/S it is sure to only get better.
FreeBSD is meant to be, much like most Linux distros, an all purpose OS, which works well on workstations, as well as servers, and in many ways is, along with OpenBSD, superior to most Linux distros.
Linux distros are unique. I personally wouldn't run anything but Debian, which is partially an exception to the point Im about to make. Most Linux distros (ala RedHat) are geared more to try to be everything to everyone. This often times leaves a Linux distro very, very open by default (ala RedHat). Linux works decently as a server OS, lacking some more advanced crypto support (by default, these things can always be installed manually, or packaged), and works extremely well as a workstation OS.
OpenBSD isn't designed to be a workstation OS, as RedHat and others seem to be geared (You really shouldn't need a server running X by default). OpenBSD is designed to be secure, and -- as Theo claims -- hasn't had a remote root exploit in the DEFAULT install in three years. THATS why I choose OpenBSD for my servers. Ports really don't matter as much to me in OpenBSD as in FreeBSD, et al, because I simply don't need them. I really don't use anything other than xntp (which is now packaged) that isn't installed by default, or that I don't compile from source myself (i.e. not from a port).
The right tool for the right job, Linux doesn't need to be everything to everyone.
(I am not responsible for my bad spelling and grammer
I just know I'm gonna get flamed for asking a Linux question in a BSD article, but is there any way to encrypt a Linux swap partition? Also, are there any ways to encrypt the data in physical RAM, in any OS?
Largely, to keep one program from snatching sensitive information from another program's swap space. Like, for example, passwords that are held in memory. A hostile program running on a box could scan through available swap in search of username/password pairs. Encrypting swap makes this less likely.
IPv6 is stable in kernel 2.4 and experimental in 2.2.x. What crack are you on?
A deep unwavering belief is a sure sign you're missing something...
www.dubbele.com has a free netbsd based firewall. Also, on the web site there's a good list of resources you may want to check out.
-John
Gee thx for that "what crack are you on?" crap. I had no idea that it was implemented stable in 2.4, but thanks for so bluntely pointing it out.
"Imagination is the only weapon in the war against reality." -Jules de Gautier
I personally had to ditch efforts to run Linux on a DEC 486 I picked up after it was decommisioned at my school. Just about everything on this PC was in awful shape, from the RAM to the HDs to the BIOS. Nevertheless, I managed to install FreeBSD 3.4 on the first shot! After a little tinkering, I had this box running _beautifully_ as a cable-sharing gateway with a few auxillary services.
IMHO, BSD has really gotten the shaft in terms of public opinion. If you ask me, it really is the better operating system. It just doesn't have the hordes of fanatics. =)
--
Just picked up a Thinkpad iSeries 1450 last week, and i've been having problems getting everything running under RH6.2 -- During my epic saga of a search for a fix, I found this page, which was tremendously helpful:
*NIX On The IBM Thinkpad
This page has a run-down of several free *NIX'es, and how they compare against eachother on the Thinkpad. Turns out OpenBSD 2.6 wins hands down.
Now I may rest.
Bowie J. Poag
Bowie J. Poag
Seriously. For those of you who haven't tried *BSD but like Linux - you should give one of the BSDs a go. Installing FreeBSD is dead easy, OpenBSD aswell. What you get is a solid and functional OS.
My first impression of OpenBSD was that "Man, they've really put some thought into this". Redhat/Mandrake and the others cram in loads of weird programs on your harddrive but the default *BSD install is very slick and slim lined. You get what you need and if you want more then go for the ports.
The ports system rocks! For those of us with fast connections it's far better than RPM. No problems with missing libraries and no hassle.
Enough of the rant. Now TRY it!
j0hn
Yes, there is such a document:
http://www.openbsd.org/faq/INSTALL.linux
OpenBSD does have ext2fs support as well.
I am the king... of No Pants! www.penny-arcade.com
OpenBSD is fantastic for servers, especially if you don't need to run KDE or Gnome apps (although, I'm sure you could figure out how to run some o' them new-fangled window managers, if you are so inclined.) If you are looking for a desktop system, though, I'd look elsewhere. Personally I don't even install X11 if I can help it.
The encrypted swap feature is not one of the points that initially sold me on OpenBSD (although it does sound über-sexy at cocktail parties). =P
It's the other, shall I say, more practical (OK, all right, probably more boring, too; but...) features that I like. Like SSH built-in, and everything locked down by default. Not necessarily cutting-edge, but nice. I sleep well at night.
Free music from Jack Merlot.
IIRC, OpenBSD swap space is only overwritten on demand. Once used, the space retains whatever information is in it until overwritten again.. A lot of useful junk, passwords, etc, is left in swap for an indeterminate amount of time. What happens when the box is stolen, say by a hostile foreign government or by the hostile local one, and they can't log in or mount your encrypted volumes? They sniff your swap space!!
.sig: Now legally binding!
Can anyone recommend a good firewall book for OpenBSD? In particular, I've got the O'reilly book, Building Internet Firewalls, and I was considering Building Linux and OpenBSD firewalls, from Wiley.
Any comments or suggestions?
No, Thursday's out. How about never - is never good for you?