Slashdot Mirror
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.)
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
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.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"
Let's encrypt everything to the point of all we get on our screen will be a bunch of useless characters
This is assuming that you could make *nix any more cryptic than it is without hitting mental critical mass. Try it, and you'll probably see the fatality rate in *nix admins soar from cranial explosion..
Shit, I may have just given Microsoft an idea..
.sig: Now legally binding!
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.)
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.
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
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.
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
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
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!