OpenBSD 5.6
openbsd.org
openbsd.org
http://bsdly.blogspot.ca/2014/10/the-book-of-pf-3rd-edition-...
And the httpd(8) manual shows there are some similarities in the configuration to Nginx. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/... It seems to be a much more simplified and streamlined setup.
Isn't this what made most of OpenSSL bugs possible and made them go unnoticed for a long time?
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.
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:
http://www.freelists.org/post/luajit/Why-does-LuaJIT-have-it...
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.
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.
Yes, and samba, and firefox. 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".
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.
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.
The documentation is exceptionally good, and the simplicity for configuration is a nice bonus.
My memory was always that ISOs were hard to find, and when I didn't see a big flashing link I guess I tuned out.
I'll revisit OpenBSD in the future, for the moment I'm enjoying FreeBSD though.
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 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.
Thankfully, it looks like they're finally gonna get there soon: http://www.bsdcan.org/2014/schedule/events/452.en.html
> The problem with FreeBSD is that it has almost no
> security features turned on by default.
ASLR is apparently around the corner+ as well.
Didn't OpenBSD get ASLR in 2008 or something like that? It only took 6 years for FreeBSD to get it.... >_<
+for some definition of corner.Why:
1. After install sometimes I do not have access or prompt access to the machine;
2. It is safe and the need for updates are minimal.
It works..
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.
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.
https://www.archlinux.org/packages/community/any/arch-wiki-d...
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.
XenServer has it worse -- no option to turn it on at all.
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.
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.
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.
http://en.wikipedia.org/wiki/DevOps
Are you asking if OpenBSD is part of people's workflow, or if it is part of their permanent infrastructure?
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..
On the other hand you can find documentation for Fedora and Ubuntu server in terms of blog-posts for just about everything.
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.
https://www.openbsdstore.com/cgi-bin/live/ecommerce.pl?site=...
I want a Wireframe Puffy Coffee Mug.
[1] https://stable.mtier.org/ [2] http://www.openbsd.org/errata56.html [3] https://twitter.com/mtierltd/status/528560775204712448
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.
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...
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.
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.
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...).
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...
The system wants to be secure, but it's not teaching me how to install it securely.
Buying the CDs is risky. How can I know they're not backdoored?
For instance, for Fedora, the download page I use (https://fedoraproject.org/pt_BR/get-fedora) has a link on the sidebar to https://fedoraproject.org/pt_BR/verify, which has a link to https://fedoraproject.org/pt_BR/keys, which has the full fingerprint for the GPG keys. That page is authenticated via TLS.
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.)
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.
This is easy for me to do. It must be the same for others.
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.
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.
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.
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).
How would you do it?
Longer answer: there are a couple linux ports of signify. http://www.linuxquestions.org/questions/slackware-14/openbsd... or https://github.com/chneukirchen/signify etc.
If you want the 5.6 key over https, here it is: RWR0EANmo9nqhpPbPUZDIBcRtrVcRwQxZ8UKGWY8Ui4RHi229KFL84wV