Related to OpenBSD, and BSD in general. Peter N. M. Hansteen is auctioning off the first signed copy The Book of PF, 3rd edition. He will be supporting the OpenBSD Foundation by donating the amount raised.
It seems this is the last version to have Nginx in the base install. 5.7 Will only ship their in-house httpd(8) as the default web server, although Nginx will still be available in ports. Reyk explained the reasoning : http://undeadly.org/cgi?action=article&sid=20140827065755&pi...
> [nginx] uses custom memory allocators (for performance reasons) and it is wrapping or replacing standard C library functions all over the place. This could eliminate some of our built-in security mechanisms.
Isn't this what made most of OpenSSL bugs possible and made them go unnoticed for a long time?
And yet techniques like custom memory allocators can have compelling performance benefits.
To me the right tradeoff is: if you want to do fancy allocation, at least make the allocator injectable so that people can use standard malloc (or even a specialized security-hardened malloc) if they prefer. Robust low-level libraries like Lua, zlib, etc. usually take this approach: you can pass a pointer to a custom "malloc" function.
Unfortunately this isn't always possible: LuaJIT doesn't support the "custom allocator" part of the Lua API for a couple of reasons:
For critical system daemons, using a custom memory allocator that disables the in-built system security is insane. Injectable allocators that fill the heap with function pointers in predictable positions are what make exploiting them easy.
Both OSX and especially Windows have extensive memory security features baked into their system allocators (ASLR, SSP, NX bit support, Guard pages, background page zeroing, etc) and even glibc has some basic security features.
Its kind of funny that windows is way ahead of your average linux distro on this front, considering the typical attitude with regards to how secure one is compared to the other.
Also its not really the BSDs that have these types of security features, its pretty much exclusively OpenBSD. FreeBSD has code support for several of these features but it is not enabled by default, and tends to break things badly when it is enabled, although work is (finally) being done to fix this situation.
ASLR: enabled by default on virtually all Linux systems, can be improved with the installation of PaX. disabled by default on Windows systems.
KASLR: Windows has it, Linux does too, but only since 3.14.
SSP: libc specific, but MSVS since 2003 has basic stack-smashing support similar to gcc's -fstack-protector which has been enabled in Debian-based distros for many years, and is now being improved over MSVC /GS with -fstack-protector-strong.
NX bit support: Support added around 2004 or XP. Again, PaX is far stronger than Windows here.
"Guard pages": This is SSP with a different name.
So at best, we can say that Windows added some security features slightly earlier, but has lagged in updating them to new standards.
I've thought that guard pages referred to the practice of having a page or a couple allocated before and after an accessible region and set to PROT_NONE (any access causes a trap) to prevent any new allocation from making those pages accessible. This way reads/writes at most a page past the beginning/end of our allocation will always fault. I don't see how is this "SSP with a different name" (the goals are similar but the method is very different). Did you mean some other kind of guard pages or am I missing something?
Full ASLR on Linux requires compiling with non-standard options (-pie -fPIE). Linux distributions seem to do this only on a case by case basis. They should've enabled these flags for most at-risk software by now, but I'm not convinced they got to all of them.
I believe so. OpenSSL had a whole swath of other issues that contributed to its problems, but chief among them was a habit of implementing core functionality already provided by the OS. Also, as mentioned, the constantly lengthening codebase made checking for such issues difficult.
OpenBSD folks have worked hard to make their functions safe and it would be a shame if a duplicate function led to a vulnerability that didn't exist in the core.
Replacing the standard C memory allocator is a stupid idea.
Incorrect. There are a lot of reasons (for tracing, for debugging, for providing fast allocations, etc.) for replacing the standard malloc() implementation in a given program.
Simply put, recall that that allocator has to be good-enough for the general case, and as such cannot be the best for any particular case. It's tricky to get right, but it's hardly a "stupid idea".
Reyk also said that people could write papers on Nginx's http implementation because it's crazy how well optimized it is. There's a BSDNow.tv interview he brings this up and talks more about the change away from Nginx.
And brings LibreSSL:
- This release forks OpenSSL into LibreSSL, a version of the TLS/crypto stack with goals of modernizing the codebase, improving security, and applying best practice development processes.
Modernizing the codebase? I think 'simplifying' is the right word. If OpenBSD is anything it is simple and easy to understand, but it is not modern. That's why it is secure.
Yes. I've commented on this sort of thing before, but my preference for OpenBSD over other things really boils down to the Just Works factor, and the simplicity and transparency of the system. I usually find that getting things going on OpenBSD is straightforward and well documented, which saves me time and aggravation. The offline factor is handy for my work, and OpenBSD really shines here.
I think the more interesting question is why OpenBSD over Linux (which distro?) or FreeBSD. For me, this comes down to preference for simplicity, an absence of weird abstractions over top of simple things like networking, and confidence in the quality of the base system. I like FreeBSD and happily use it in several instances (freebsd-update is pretty great for online updating), but have had very mixed results with Linux systems (mostly debian and ubuntu). Sometimes things work, and sometimes I waste hours trolling through internet forums trying to figure out how to make it do what I want.
Really though, if you want to know what the difference is, you should just try it. Pull down the ISO, fire up a VM, do the install, and then try to get some work done. Take the time to read the man pages for afterboot, pkg_add and rc.conf.local, and you'll be on your way. The worst that could happen is you don't like it..
Hm, my only problem with my FreeBSD VPS is that ruby is terribly slow... I think it's the VM that slows down the ruby interpreter. Other than that, as you said BSD is way easier to maintain and configure because of it's clarity and documentation compared to Linux.
On the other hand you can find documentation for Fedora and Ubuntu server in terms of blog-posts for just about everything.
Curiously, the reasons that you use OpenBSD are the reasons that I use Linux, it Just Works for me and I've had problems when trying to use BSD.
As I talk to more people about it, there seems to be a growing pattern that, it's just whatever system you grew up with is the one you're most comfortable with, and is the one you're most likely to use going forward.
I grew up with linux. Back when slackware was king. I've always found it to be a constant source of irritations and problems. I tried out openbsd in 2001 or so and immediately jumped ship. And since then linux and most distros built on it have only gotten more complex, while openbsd has not. There is definitely more to it than "whatever people are used to".
Most of my work is server side (vim!), but on a client I just install firefox-esr with pkg_add. If there's a security update that I think I need, I'll 'make package' on the -stable branch in ports, and install that package wherever I need it. The -current branch keeps up to date with firefox pretty well if you want all the new features, but -current tends to move faster than I'm willing to keep up with.
OpenBSD is what I use to host a bunch of private sites for myself and a few people I know. This is only due to some custom configurations and applications that my shared webhost didn't provide and for things I can't be bothered with, like my own domain which is static html. I put them on the shared host.
I wish it was for a lofty goal like security and "code correctness" etc... but the honest answer is that it's extremely simple (once you get used to it) and I tend to be extremely lazy at times. Configuration is very straightforward for a lot of things and there have been very few surprises along the way. Actually no surprises that I can recall in most of what I do since 5.0.
I wouldn't recommend it as a desktop system although plenty of people (including my boss) use it as such. There is some fiddling required for this that I'd rather not do, but for very simple, stable and surprise-free servers, it works very well for me. I also wouldn't recommend it for first-time admins either, although their man pages are some of the most thorough and helpful I've ever read.
> I wouldn't recommend it as a desktop system although plenty of people (including my boss) use it as such. There is some fiddling required for this
I've been running OpenBSD on a laptop (which works as my desktop) for years now, and I can say there's been very little fiddling. In fact it's proved to be the best out-of-the-box experience I've had with any OS (including Windows XP and a whole bunch of Linux distros).
> I also wouldn't recommend it for first-time admins either
I have to admit I wasn't administrating things for the first time when I did it on OpenBSD.. but OpenBSD was so simple and straightforward that I eventually lost the will to fiddle with other systems.
They really have gone out of the way to make sure the system is Dead Simple to configure (the best configuration is no need for any configuration at all!), and when you really need to change something, the documentation is unparalleled.
Of course, different people have different needs so what works for me might not work for everyone. I know that what seems to work for most people doesn't really work for me...
> I've been running OpenBSD on a laptop (which works as my desktop) for years now, and I can say there's been very little fiddling. In fact it's proved to be the best out-of-the-box experience I've had with any OS (including Windows XP and a whole bunch of Linux distros).
I think with any BSD, trying to run it on modern hardware will be a frustrating experience as it lags behind Linux in hardware support (which itself lags behind Windows/OSX). Of course, BSDs are more coherent OSes and if it were not for hardware support I would use it exclusively.
I use OpenBSD on my laptops and desktop. The KMS drm drivers have been improved for 5.6. So you have 2D/3D acceleration, and unlike with FreeBSD, Xorg just works without configuration out of the box.
For a more "desktop" experience, OpenBSD 5.6 also has working GNOME 3.12.2.
One thing that tends to trip up desktop users is the default ulimits, BSD has login classes which may need to be tuned in login.conf(5). This is especially true if you plan on using modern web browsers which are resource hogs.
It seems I have to revaluate my stance on this. I admit, it's been a while since I ran OpenBSD as a full desktop. I've been happy with Crunchbang Linux so far as a simpler system, but maybe it's time I tried it again.
OpenBSD has had downloadable ISO for a long time. It is easily reachable from ftp or http. FreeBSD's site requires for and takes more clicks to get to.
I installed freebsd on an old laptop (thinkpad t60) because I want to use something simple, very well documented, and with an emphasis on good code. I know OpenBSD takes this further, but I know FreeBSD has more packages/ports available, and I'm interested in playing with ZFS and jails.
I hack on my OSS project on OpenBSD exclusively. I'm a stickler for good documentation, and the BSDs IMO are far better than Linux.
I use OpenBSD because 3-4 years ago I discovered a bug in the FreeBSD kernel that meant my OSS project wouldn't work. When generating lots of IGMPv2 packets on FreeBSD I could consistently cause the kernel to panic. I wrote a bug report, but I'm not a kernel hacker so I just switched to OpenBSD.
Manpages in Linux are atrocious, and each distro has their own way of doing things that only half works. I don't like GNU info, and Googling for docs is unacceptable. I often work in places with no Internet and I need the doc with me.
This is very true, its navigation is awful. Luckily there is one programme that makes info pages less annoying to browse. It's called 'pinfo', feels similar to lynx, and although it doesn't show from the website, it's a useful tool, nicer than the regular 'info'.
I guess I'm biased as an Arch user but I've found their documentation to be leagues ahead of everything else I've used. That said, it doesn't solve the offline access issue you raised and the BSDs are firmly in second place.
That said, I've been starting to care quite a lot more about security and code correctness in light of recent events and have been waiting for today to install OpenBSD on my machine.
You'd put the bsd handbooks in second place after the Arch wiki? The FreeBSD handbook seems a lot more impressive and coherent to me, so does the OpenBSD documentation.
They're a bit hard to compare imo. The FreeBSD documentation is more coherent but also more focused/narrow, covering only the base system and a few common extensions. The Arch documentation is less coherent, but quite extensive, covering almost everything. I think the Arch wiki is less good as a proper manual, something you'd sit down and read cover to cover as an introduction to the system. But one thing that's nice about it is that it's really a one-stop shop: if you want to know what some package does, how it works, and how to configure it, it's probably there. If it doesn't play nicely with Arch or needs a workaround for common issues, chances are it's documented there too. Whereas with FreeBSD you're good as long as you stick with the base system, but it's a wilderness once you venture out into ports, with documentation/tips/workarounds scattered across the web, forums, mailing lists, StackOverflow, etc.
Further related, does anyone know of a rented server company that offers OpenBSD? Ideally a sort of Linode for OpenBSD, although I understand with the virtualization fun that's mildly unlikely to be a 1:1 equivalence.
I can't be the only person that wants to deploy Linux based services piped through pf on OpenBSD and doesn't want to get into colocation.
I've been a happy customer of ARP Networks [0] for about five years now (running Linux, FreeBSD, and OpenBSD hosts). I've pretty much moved everything off to my own servers (since I work for an ISP and can put whatever I want in our datacenters) but I do still have one VPS hosting a few websites.
Native IPv6 is enabled on every host which, as a network engineer, is a huge plus for me. Physical location is at One Wilshire in Los Angeles and ARP has great connectivity and lots of peering.
It's a small operation which, depending on your point of view, can be either a good thing or a bad thing. There is no "instant provisioning" (or wasn't, the last time I ordered a new host) so it may take a day or so for your host to be available for your use. On the other hand, you can often catch the owner in #arpnetworks on freenode and chat directly with him (or get quick answers to (general) questions from other happy customers). He's also on HN occasionally, if memory serves.
I'm using filemedia[0]'s KVM-based offering. It supports custom ISOs (you can open a ticket to get a new ISO uploaded),
so installing OpenBSD (5.4 at the time) was quite easy.
You just have to make sure to use DHCP and not a static IP in the network configuration, otherwise the network stops working a few months later when the DHCP lease expires.
They also have a new Xen (PV or HVM) oferring, but I don't know how well OpenBSD would work with that.
Another possibility is iwStack[1], another KVM-based hosting provider.
Not really DevOps, but it's my main ("desktop") OS. I know it well, it's pretty damn secure, and it's an excellent development environment - good docs and lots of features that crash bad software.
No not at work. At home I use it on my two routers, one alix and one apu board.
I ran into a huge backset with openbsd at work 3 years ago when I wanted to run two redundant load balancers with carp in vSphere. Turns out I had to enable promiscuous mode on an entire port group to make it happen. These days we use virtual switches so maybe it's easier now but in those days we did not want to do it because it would mean enabling promiscuous mode on an esx host adapter, affecting everyone on that host.
OpenBSD 5.6 isn't quite released yet, it's still not on the master site. The announcement will undoubtedly be going out soon though, and it's on a few mirrors if you wish to jump the gun.
Hm, ripping kerberos from libssl I can understand -- but from base? Does that mean that openssh certificate is what people are using for federated authentication? While kerberos is complex and complected -- are there any solutions that are better, if you require administrating a non-trivial number of users, along with a good way to immediatly revoke access as users leave the organization?
Sure. But authentication and authorization of users isn't like showing a static (or dynamic) web page (ie: simpler httpd vs more full-featured nginx).
I'd say moving it out of base is a pretty strong signal to OpenBSD users. (Now, granted, kerberos have and have had perhaps more than its share of issues ... so the signal could just be: you probably shouldn't have been depending on this to be secure enough to grant access to the server in the first place).
I'm more curious if this means OpenBSD (base) doesn't have any form of secure(ish) federated auth(z) story (other than ssh certs) any more.
That is not Single-Sign-On, if you have to sign on several times. LDAP is NOT a replacement for Kerberos.
OAuth and alike might be, but when you work with internal users Kerberos is much much better. Also for web services because GSSAPI/spnego stuff just works.
By removing kerberos from base setup openBSD people have once more moved towards irrelevance outside their own closet setups. Kerberos is the only really working method you can use in corporate setups for large amounts of users and achieving SSO. When it's not in base setup, it's just easier to install any decent Linux distro, and skip openBSD. That as market placement decision was yet another major blunder from openBSD folks, and still they wonder why their donations have dried up the last a few years...
Sorry, I didn't really get that single-sign-on and federated authentication is the same thing.
Couldn't you just install Kerberos from ports/package? Most Linux distribution don't come with Kerberos in their base system. I honestly don't believe that a winning argument for pick OpenBSD over Linux would be: "Kerberos is in the base install".
I would agree that is't a bit odd that login_krb5 seems to have just gone away, delete from CVS, but not moved to the ports three. It might be that so few people actually used it that there's no one to maintain it.
> Sorry, I didn't really get that single-sign-on and federated authentication is the same thing.
I don't think it is. SSO is a good feature, and kerberos provides it -- but I was more curious about the more general case. A solid ldap daemon with easy-to-use ssl/tls covers most of the use-cases I was thinking of.
I don't really care much about "winning arguments" -- I'm just curious about the state of secure, working federated authentication. And the fact that it needs to grip rather deeply into the system, therefore it would be nice to have it in base. Linux generally has PAM in base -- for some that is considered bad, for some it is considered convenient. I'm not really interested in judging one way or the other.
> It might be that so few people actually used it that there's no one to maintain it.
Yeah, that's the feeling I got. And it would be worse to keep something that isn't properly maintained. I guess I'd hoped some openbsd'er would hammer out a robust token/ticket based scheme without many of the flaws of kerberos (ie: hardened implementation, proper/modern cryptography primitives combined in a proper modern way, no premature optimization). That'd probably be hopeless to get to work with windows AD though, so maybe there's only a very small set of people that would care.
I'd certainly like (from a technological standpoint, anyway) something like that, that took lessons from window's kerberos/ldap/dns-story, but made something free and robust (possibly with a patch for GINA for windows) -- that allowed stuff like secure encrypted network filesystems etc.
(Come to think of it, I think the fact that I'm sort of enamoured by the concept of NFSv4 with authentication and encryption delegated to kereberos is one of the reasons why I was so surprised/disappointed. Why have ZFS and NFS without v4 and auth/enc support? So beautiful on paper. I guess that basically leaves sshfs (as OpenAFS also requires(?) kerberos).
I'd really like to see a working distributed single-sign on, single sign-off system that support (optional) caching/offline use coupled with a filesystem that is mutually authenticated (client to server, server to client) also with caching and off-line use. But that is simpler than efforts that have gone before...).
Since when did OpenBSD give a crap about market placement?
It was always about correctness and security. They don't keep big complex unaudited piles of crap around for the sake of corporate or mass market appeal.
Nobody was using kerberosV, nobody was interested in auditing it. There's no place for code like that in OpenBSD base.
So, for me the trust chain for the Fedora installation DVD is:
- The trust chain root is my current browser (a recent enough version of Firefox);
- The browser trusts the CAs in its certificate store (the built-in CA certificates from Mozilla, plus the ICP-Brasil CA certificates);
- One of these CAs verifies the certificates for the fedoraproject.org pages;
- From these pages, I download a set of public GPG keys, and if I want I can verify their fingerprints;
- The torrent for the installation DVD has the DVD image and a checksum file. I use GnuPG to verify the signature on the checksum file, and check the page to confirm that it was signed with the correct key;
- Finally, I verify the SHA256 of the DVD image and confirm that it matches the value found in the checksum file.
I don't know how I would do it for OpenBSD. The www.openbsd.org page doesn't seem to be available over TLS, so I can't use the CAs trusted by my browser to bootstrap the trust chain. If I had OpenBSD 5.5 installed, I could use it as the root of the trust chain (as explained at the link you posted), but unfortunately I don't have it installed anywhere, so that trust path doesn't work for me.
If I had an OpenBSD 5.6 ISO in hand right now, what could I do to authenticate it? (Assume I have a recent Linux or BSD system to start with.)
The official way of doing this is to buy the CD set in which the code and keys are sent via different channels. You buy the CD set and it is mailed to you. You then verify that against the key on the web site.
If the verification fails, either the CD set or the key is compromised.
I really wouldn't trust a CA or shared PKI to do this to be honest as that means you have to trust three or more parties rather than just two.
Networks are easy to attack if you have control over the ISP. Mail can be easily replaced by one single person monitoring someone's mail.
A company where employees get their mail at work and only access the net from work could do both easily.
I don't have resources for something like this, but doing this isn't as difficult as it might seem. A big enough adversary with enough resources could compromise everything used in security sensitive environments.
I wanted to know if anything changed in how OpenBSD can be installed securely. It is easier to obtain other operating systems securely. They are less secure, but the authenticity of the iso files can be verified via signatures.
This uncertainty has stopped me from using OpenBSD in the past. I have the same questions now.
This is a question about obtaining an iso file to install OpenBSD knowing it's what the developers sent out, just like checking a sha256 signature for other operating systems when downloading. It's not a question about using it in a government agency.
Thanks for the replies. You probably have more useful things to do than discuss this.
If it is so easy to attack, then you already lost the game unless you've pinned the fedoraproject certs. The CA model has been demonstrated broken long ago.
So would you rather trust that model, or just obtain the OpenBSD key for yourself via multiple different channels, from multiple sources? The key, by the way, is all over the place. You start with the official site, but you can cross-check against all the CVS mirrors, and you can check all mailing list archives which contain the key in the release announcement.
I would dare say that is heck of a lot better than simply trusting your CAs, if you are indeed so easily attacked.
Without TLS and having control of the network, it doesn't matter how many channels over the network you use; it's simple to MITM everything and search-and-replace all text matching the key with your forged key (in fact, many networks already MITM all non-TLS HTTP traffic through a "transparent proxy").
With TLS, even with the imperfect CA model, it's much harder. It might have been "demonstrated broken", but can you get a certificate for "fedoraproject.org"? It's not that easy. Add to that the Certificate Patrol extension, which warns the user quite noisily when a certificate is signed by a different CA (and shows the user the old and new CA).
With mailing the CDs, as suggested several posts upthread, it also gets harder; now the attacker has to MITM two things (the network and intercept the physical disks). If you add TLS, it gets even harder (three things: MITM the network, intercept the physical disks, and obtain a valid forged certificate).
So, trusting the CAs is better than getting the key via multiple unencrypted channels through the same network. Trusting the CAs plus getting the key via multiple channels is even better. The methods are not exclusive, and "multiple channels" is already common in practice (in my Fedora example, the DVD image is obtained via bittorrent, while the key is obtained via TLS, and they have to match).
I think you may have a little too much faith in the gnupg binaries and ca list and whatnot you have now. Remember, at some point you got them over the same untrusted channels.
Yeah, but the gnupg binaries and CA list and browser executables and whatnot were validated by the package manager, which came from a install disk validated by older gnupg binaries and CA lists and browser executables and so on...
In the end, the trust chain stretches to files downloaded using Netscape 2 via dialup sometime in the last millennium.
Yeah, the chain might have been broken a few times in the meanwhile. Still, it's better to chain from what you have than to start from scratch every time. The more you do it, the longer the chain stretches. And it takes just one person with an unbroken chain from before the attacker has even been born to sound the alarm.
http://bsdly.blogspot.ca/2014/10/the-book-of-pf-3rd-edition-...