

OpenBSD 5.6 - fcambus
http://www.openbsd.org/56.html?hn

======
brynet
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.

[http://bsdly.blogspot.ca/2014/10/the-book-of-pf-3rd-
edition-...](http://bsdly.blogspot.ca/2014/10/the-book-of-pf-3rd-edition-is-
here.html)

------
eksith
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...](http://undeadly.org/cgi?action=article&sid=20140827065755&pid=24)

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/...](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man8/httpd.8) It seems to be a much more simplified and streamlined
setup.

~~~
gioele
> [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?

~~~
haberman
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:

[http://www.freelists.org/post/luajit/Why-does-LuaJIT-have-
it...](http://www.freelists.org/post/luajit/Why-does-LuaJIT-have-its-own-
allocator)

[https://gist.github.com/nddrylliog/8722197](https://gist.github.com/nddrylliog/8722197)

~~~
aortega
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.

~~~
masklinn
On the other hand, as far as I know most systems don't bundle security
features in their standard allocators. I'm not sure any non-bsd system does.

~~~
throwaway2048
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.

~~~
Hello71
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.

~~~
robryk
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?

------
lmedinas
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.

~~~
w8rbt
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.

~~~
tedunangst
Well, modernizing as in using modern functions like 'memmove', even though
they may not exist on SunOS 4.1.

------
sauere
Semi-related: is anyone here using OpenBSD in their daily DevOps setup? If so,
why did you choose it (say, over Linux or FreeBSD)?

~~~
eksith
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.

~~~
clarry
> 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...

~~~
Touche
> 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.

------
brynet
You can order the 5.6 CD set from the new OpenBSD Store, there's also older
sets and other swag.

[https://www.openbsdstore.com/cgi-
bin/live/ecommerce.pl?site=...](https://www.openbsdstore.com/cgi-
bin/live/ecommerce.pl?site=shop_openbsdeurope_dollar&state=department)

I want a Wireframe Puffy Coffee Mug.

------
brynet
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.

~~~
brynet
..and now here it is released! 5.6 is official.

[http://marc.info/?l=openbsd-
announce&m=141486254309079&w=2](http://marc.info/?l=openbsd-
announce&m=141486254309079&w=2)

------
e12e
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?

~~~
Mordak
It was just moved from base to ports, so you can still get it from
ports/security/heimdal if you want it.

~~~
e12e
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.

~~~
mrweasel
You could use LDAP, that's in base. There's even an small OpenBSD LDAP daemon
actively maintained by the OpenBSD proejct.

~~~
erglkjahlkh
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...

~~~
mrweasel
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.

~~~
e12e
> 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...).

------
farawayea
Is installing openbsd securely possible using hash checks and signing?

~~~
brynet
OpenBSD 5.5 and 5.6 include signify(1) for both signing and verifying signed
files.

[http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man1/...](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man1/signify.1?query=signify&sec=1)

~~~
farawayea
What is the secure install process? Are there signatures for packages and for
the iso file?

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?

~~~
tedunangst
Read the install docs and search for "sign".
[http://ftp.openbsd.org/pub/OpenBSD/5.6/amd64/INSTALL.amd64](http://ftp.openbsd.org/pub/OpenBSD/5.6/amd64/INSTALL.amd64)

~~~
cesarb
Forgive me if I'm missing something, but I don't see how to "bootstrap" the
trust from an existing, non-OpenBSD system.

For instance, for Fedora, the download page I use
([https://fedoraproject.org/pt_BR/get-
fedora](https://fedoraproject.org/pt_BR/get-fedora)) has a link on the sidebar
to
[https://fedoraproject.org/pt_BR/verify](https://fedoraproject.org/pt_BR/verify),
which has a link to
[https://fedoraproject.org/pt_BR/keys](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.)

~~~
cowabunga
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.

~~~
farawayea
This mailing of cds seems silly. An attacker could compromise the cds to be
different and serve you another signature on the site.

This is easy for me to do. It must be the same for others.

~~~
tedunangst
It's easy for you to intercept somebody's mail and internet connection? Who do
you work for?

~~~
farawayea
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.

~~~
clarry
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.

~~~
cesarb
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).

~~~
clarry
By multiple channels I mean not just channels over a single network. You can
access all these key sources from different networks.

