Thanks for highlighting this. For me, OpenBSD releases needed so few fixes that keeping the system up to date wrapped around, and become more of a hassle to deal with! I'd get an email and have to manually rebuild something. Watching yet another flood of compiler output started feeling like a huge waste of time, despite only happening once every month or two.
For personal use, on debian I set a cron job and forget it. This utility hits the sweet spot to get me running OpenBSD again.
I keep running into a weird issue where my Debian servers won't shut down ("A start job is running for Unattended Upgrades") when I enable unattended upgrades as described at [1]. It is especially weird since my Debian systems are otherwise pretty bare-bones, yet the issue occurs on several of them. The solutions listed on Stack Exchange [2] seem rather hacky.
A (highly subjective) selection of things that seemed interesting, sorted from most to least noteworthy in my opinion
--
- A lot of code has been removed or simplified to make the transition to multi-processor easier.
- printf(3) family of formatting functions now report to syslog when the %s format is used with a NULL pointer.
- When sending TCP streams they are locally stored in large mbuf clusters to improve memory management. The maximum TCP send and receive buffer size has been increased from 256KB to 2MB. Note that this results in a different pf(4) OS fingerprint for OpenBSD.
- ssh(1): Add a proxy multiplexing mode to ssh(1) inspired by the version in PuTTY by Simon Tatham. This allows a multiplexing client to communicate with the master process using a subset of the SSH packet and channels protocol over a Unix-domain socket, with the main process acting as a proxy that translates channel IDs, etc. This allows multiplexing mode to run on systems that lack file-descriptor passing used by current multiplexing code) and potentially, in conjunction with Unix-domain socket forwarding, with the client and multiplexing master process on different machines. Multiplexing proxy mode may be invoked using "ssh -O proxy ..."
- OpenSSH 7.4: Server support for the SSH v.1 protocol has been removed. {NB, note the "server" bit - "client" is not mentioned}
- Support for Linux guest VMs.
- The performance and concurrency of the malloc(3) family in multi-threaded processes has been improved.
- read(2) on directories now fails instead of returning 0.
- Support for permitting non-root users to mount(8) filesystems has been removed.
- Install sets are now fetched over an HTTPS connection by default when using a mirror that supports it.
- For incoming TLS connections syslogd(8) can validate client certificates with a given CA file.
- nc(1) now also supports OCSP stapling server side, and will show the stapling information client side.
- When log files are rotated, newsyslog(8) writes the creation time in UTC ISO format into the first line.
--
- sshd(8): Remove the UseLogin configuration directive and support for having /bin/login manage login sessions.
- sshd(8): Add a sshd_config DisableForwarding option that disables X11, agent, TCP, tunnel and Unix domain socket forwarding, as well as anything else we might implement in the future. Like the 'restrict' authorized_keys flag, this is intended to be a simple and future-proof way of restricting an account.
- sshd(8), ssh(1): Support the "curve25519-sha256" key exchange method. This is identical to the currently-supported method named "curve25519-sha256@libssh.org".
- Deprecate the sshd_config UsePrivilegeSeparation option, thereby making privilege separation mandatory. Privilege separation has been on by default for almost 15 years and sandboxing has been on by default for almost the last five.
- SHA512_256 family of functions added to libc.
- LibreSSL 2.5.3: Massive update and normalization of manpages, conversion to mandoc format. Many pages were rewritten for clarity and accuracy. Portable doc links are up-to-date with a new conversion tool.
--
- Use a hardware register for the thread pointer on arm for improved performance in multi-threaded processes.
- New vmm(4)/ vmd(8): Support was partially integrated in 6.0, but disabled.
- vmm(4) no longer requires VMX unrestricted guest capability (Nehalem and later CPUs are sufficient).
- Support VMs with > 2GB RAM.
- vmd(8) uses pledge(2) and the fork+exec model.
--
- All shared libraries, all dynamic and static-PIE executables, and ld.so(1) itself use the RELRO ("read-only after relocation") design such that more of the initial data is protected as read-only.
- The privileged parent process of syslogd(8) calls exec(2) to reshuffle its random memory layout.
- New function recallocarray(3) to reduce the risk of incorrect clearing of memory before and after reallocarray(3).
The fact that LLVM is now finding some official use (in the arm64 port), combined with the retirement of a couple more platforms, strongly signals that OpenBSD might very well switch to LLVM/clang (and away from GCC, which has very much non-ideal licensing terms).
It's the first release without an official CD set [1], and OpenBSD was probably one of the last operating systems to provide official installation discs. I wonder if they'll start recommending third-party sellers of installation CDs and DVDs like Debian does [2].
The disks were apparently stopped because they no longer provided a relevant amount of profit-per-work - making CD's requires a lot of coordination work, and worldwide shipping isn't trivial.
Massive update and normalization of manpages, conversion to mandoc format. Many pages were rewritten for clarity and accuracy.
Most of OpenSSL's documentation desperately needed attention and was full of extremely minor errors that rendered some parts unintelligible - for example, this confusing single character one that was already fixed in LibreSSL : https://github.com/openssl/openssl/commit/a41815f05e71009d2a...
In addition to what has been said, any provider that provides a (RAM-based) rescue system will likely allow you to install OpenBSD by running the OpenBSD installer in qemu, with the 'real' disks mounted as the VM's disks.
This is not a supported or convenient way to do your first OpenBSD install. Having a serial console is not necessary, but recommended (in particular, don't forget to configure <real-hw-interface>0, not the em0 that qemu is likely to offer you.) That said, I've done this before on some Hetzner serverauction (bare-metal) box, and the procedure worked fine (as one would expect.)
(Of course, you can run into hardware that OpenBSD doesn't support. Consult the man pages to find what is supported, or just try - server hardware is pretty likely to be supported.)
Sadly I don't often get to play with OpenBSD, but every time I do I'm impressed by how coherent an operation system it is. You really get the feeling that the developers care about delivering a system with a unified expression, where everything is meant to be used together.
It's not just kernel bundled with a bunch of tools/programs which sort of seem to work together, but not in the same manor. Even FreeBSD have sometimes left me with the impression that the developers don't care about style and just import tools or subsystems at leave it at that, rather than making it feel like it belongs.
Heh, as a FreeBSD user primarily, OpenBSD sometimes feels kinda empty to me. No ZFS, no DTrace, no jails, no mandatory access control, no CloudABI, no Linux compat layer…
I agree with both of these sentiments. I think that's because OpenBSD prefers to move more slowly until they can be sure a thing is absolutely right. Innovation in OpenBSD tends to be unsexy and carefully considered. FreeBSD pushes the envelope in a lot of areas to deliver features, with more inherent risk.
Both are valid, and result in very different operating systems. These days most of my work can be fit into the OpenBSD envelope, which makes me feel especially good.
DTrace would be nice to have, but I believe there are CDDL license concerns.
Jails are a way of isolating services so that they cannot do (much) damage to the system in the event they are compromised. The closest alternative in OpenBSD is probably pledge(2), which allows a program to voluntarily renounce the ability to invoke a set of syscalls. There is also chroot if all you need is filesystem virtualization.
> OpenBSD doesn't support a MAC framework because they believe the best approach to security is correctness, rather than trying to achieve security by adding features which results in more complexity, making it more difficult to ensure correctness. A common mistake people make is thinking that OpenBSD's primary goal is security; their primary goal is correctness. This just happens to result in better security more often than not.
Linux compat is a similar story. OpenBSD dropped it in the 6.0 release due to complexity and security concerns.
pledge is not similar to jails in any way, jails are "chroot on steroids" (isolate network, PIDs, users, etc.)
pledge is more similar to Capsicum. It is simpler to implement in some programs, sure, but:
1) I don't like how pledge just kills the program. Rude. Capsicum refuses the offending operation.
2) Capsicum has an absolutely brilliant feature for directory access — you just open() a file descriptor to a directory, then you cap_enter()… and in the sandbox mode you can use openat() to open files below that directory! This is just so clever. Meanwhile pledge promised a simple directory whitelist option that is STILL NOT IMPLEMENTED :(
CloudABI is a portable ABI that can be described as POSIX plus Capsicum minus anything incompatible with Capsicum. So CloudABI programs start already in capability mode, expecting necessary file descriptors to be already open (there's a launcher tool for that). You can just run CloudABI binaries unmodified on several operating systems and they are always sandboxed, they have no way to access anything you didn't pass to them. CloudABI is out-of-the-box supported on FreeBSD, there are kernel patches for NetBSD and Linux, and a user-mode syscall translator for macOS. https://nuxi.nl/cloudabi/
I actually don't disagree with that, all those features would be nice to have in OpenBSD. However, ZFS for example is "just pulled in" from Solaris and seems a little out of place. It works great, but there seems to be no effort to make it feel like belong.
That's not really true. There has been work to follow in TrueOS's footsteps to have a full ZFS root and integrate that with the installer, system upgrade, et al. as TrueOS does. TrueOS has been leading the way for using ZFS for boot environments on FreeBSD. This is far from "no effort".
Fair enough, though that wasn't really what I meant. I was think in terms of reworking the tools or either using the fstab for ZFS or forgo using it for any filesystem.
I completely understand why these thing aren't being done, but not doing them mean that something will remain a little out of place.
Yeah, SO_PEERCRED, I remember that one. The sway Wayland compositor relies on it to authenticate privileged programs (desktop bars, screensavers, screenshot tools etc.) When I was porting sway, that really annoyed me.
Is there a router/firewall distro or administration tool for OpenBSD that's recommendable (e.g. like pfsense without all the enterprisey bloat, or like securityrouter without the licensing stuff)?
TrueOS is making rapid improvements to their sysadm tool (client/server system for managing TrueOS machines), iirc (from a recent BSD Now episode) there's work going into improving the firewall management interface. This isn't really a recommendation to switch to TrueOS, but it is a recommendation to keep an eye on their progress.
[edit] D'oh, for some reason I read "like pfsense" but missed "for openbsd."
For what it's worth, PF is a lot easier to work with than iptables. The configuration files involved (namely: pf.conf) are easy to read/write and well-documented.
Maybe this isn't the best place to ask this, but how does OpenBSD handle "real world" security these days? Last time I checked, OpenBSD was heavily audited, with emphasis on shipping a secure base system. The problem, to me, is that every running system in the world has many packages installed to make it useful as an e.g. server. What use is a secure base system if installable packages aren't audited to the same degree? Debian handles this by putting all packages (apart from universe) under the maintenance of the Debian Security Team. I would love to use OpenBSD, but want to make sure that the extra effort isn't spent with no real security advantage.
Universe is an Ubuntu thing. Debian doesn't have that distinction. On Ubuntu, universe is basically packages straight from Debian not directly supported by Ubuntu.
Most (all?) ports than run servers get an unprivileged user all to their own (_dovecot, _nginx, etc). Many (including desktop packages like Chromium) also have pledge() support patched in.
There is a lot of functionality in Base that some aren't aware of: ldapd, httpd, IPSec + iked (VPN), pf (firewall, NAT), dhcpd, ntpd, smtpd, snmpd, radiusd, relayd (load balancer), tftpd, sshd, nfs, nsd and unbound (DNS)
So, you could run an HTTPS site, with a Perl fastCGI site, sending emails, all out of Base
Yes, built in pf, dns and dhcp alone make for a nice little home router that I trust more than an off the shelf model. Pretty easy to set up too, config files in OpenBSD are generally straightforward and easy to get right the first time. I definitely found nsd easier to setup than bind.
Xenocara may not satisfy performance characteristics the way something like Wayland is. However, Xenocara is pretty awesome in (I believe) being the only X11 server to address the somewhat ugly security model of stuff running as root.
I think most of the popular Linux distributions have been shipping rootless x11 for a few years now, too. Kernel Mode Setting was the big watershed feature.
In addition to the other things people have mentioned, it also now has vmm/vmd. Also, much of the ported software has patches to make better use of OpenBSD mitigations, some make use of pledge(2).
82 comments
[ 3.2 ms ] story [ 143 ms ] threadThanks for highlighting this. For me, OpenBSD releases needed so few fixes that keeping the system up to date wrapped around, and become more of a hassle to deal with! I'd get an email and have to manually rebuild something. Watching yet another flood of compiler output started feeling like a huge waste of time, despite only happening once every month or two.
For personal use, on debian I set a cron job and forget it. This utility hits the sweet spot to get me running OpenBSD again.
You can specify the types of updates to auto install (ie I use security updates only automatically).
[1] https://wiki.debian.org/UnattendedUpgrades#automatic_call_vi...
[2] http://unix.stackexchange.com/questions/293804/debian-a-star...
I'm not sure this has been reported before / correctly:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837155 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719597
Maybe give the maintainers a prod with a link to that thread?
* https://marc.info/?l=openbsd-tech&m=149048271705188&w=2)
--
- A lot of code has been removed or simplified to make the transition to multi-processor easier.
- printf(3) family of formatting functions now report to syslog when the %s format is used with a NULL pointer.
- When sending TCP streams they are locally stored in large mbuf clusters to improve memory management. The maximum TCP send and receive buffer size has been increased from 256KB to 2MB. Note that this results in a different pf(4) OS fingerprint for OpenBSD.
- ssh(1): Add a proxy multiplexing mode to ssh(1) inspired by the version in PuTTY by Simon Tatham. This allows a multiplexing client to communicate with the master process using a subset of the SSH packet and channels protocol over a Unix-domain socket, with the main process acting as a proxy that translates channel IDs, etc. This allows multiplexing mode to run on systems that lack file-descriptor passing used by current multiplexing code) and potentially, in conjunction with Unix-domain socket forwarding, with the client and multiplexing master process on different machines. Multiplexing proxy mode may be invoked using "ssh -O proxy ..."
- OpenSSH 7.4: Server support for the SSH v.1 protocol has been removed. {NB, note the "server" bit - "client" is not mentioned}
- Support for Linux guest VMs.
- The performance and concurrency of the malloc(3) family in multi-threaded processes has been improved.
- read(2) on directories now fails instead of returning 0.
- Support for permitting non-root users to mount(8) filesystems has been removed.
- Install sets are now fetched over an HTTPS connection by default when using a mirror that supports it.
- For incoming TLS connections syslogd(8) can validate client certificates with a given CA file.
- nc(1) now also supports OCSP stapling server side, and will show the stapling information client side.
- When log files are rotated, newsyslog(8) writes the creation time in UTC ISO format into the first line.
--
- sshd(8): Remove the UseLogin configuration directive and support for having /bin/login manage login sessions.
- sshd(8): Add a sshd_config DisableForwarding option that disables X11, agent, TCP, tunnel and Unix domain socket forwarding, as well as anything else we might implement in the future. Like the 'restrict' authorized_keys flag, this is intended to be a simple and future-proof way of restricting an account.
- sshd(8), ssh(1): Support the "curve25519-sha256" key exchange method. This is identical to the currently-supported method named "curve25519-sha256@libssh.org".
- Deprecate the sshd_config UsePrivilegeSeparation option, thereby making privilege separation mandatory. Privilege separation has been on by default for almost 15 years and sandboxing has been on by default for almost the last five.
- SHA512_256 family of functions added to libc.
- LibreSSL 2.5.3: Massive update and normalization of manpages, conversion to mandoc format. Many pages were rewritten for clarity and accuracy. Portable doc links are up-to-date with a new conversion tool.
--
- Use a hardware register for the thread pointer on arm for improved performance in multi-threaded processes.
- New vmm(4)/ vmd(8): Support was partially integrated in 6.0, but disabled.
- vmm(4) no longer requires VMX unrestricted guest capability (Nehalem and later CPUs are sufficient).
- Support VMs with > 2GB RAM.
- vmd(8) uses pledge(2) and the fork+exec model.
--
- All shared libraries, all dynamic and static-PIE executables, and ld.so(1) itself use the RELRO ("read-only after relocation") design such that more of the initial data is protected as read-only.
- The privileged parent process of syslogd(8) calls exec(2) to reshuffle its random memory layout.
- New function recallocarray(3) to reduce the risk of incorrect clearing of memory before and after reallocarray(3).
- arm added to the l...
- The iwm(4) driver now supports 802.11n MIMO (MCS 0-15).
- Enforcement of userland W^X on OCTEON Plus and later.
Is the EdgeRouter Lite an Octeon "Plus"?
- LLVM/Clang 4.0.0 (+ patches)
Looks like they shipped LLVM 4 into an actual stable release before FreeBSD! (because it's the first LLVM for them)
- New tpm(4) driver for Trusted Platform Module devices.
But that one was in FreeBSD since 2010 :P
Note it's only in base for the ARM platform.
Looks like:
[1] https://www.openbsd.org/orders.html [2] https://www.debian.org/CD/vendors/
https://www.openbsd.org/faq/faq4.html#MkInsMedia
Goodnight, sweet prince.
The Sharp Zaurus was where I first ran OpenBSD.
SPARC is one of the few unencumbered platforms without security bits (Intel ME or AMD PSP) and GPL cores: https://news.ycombinator.com/item?id=11423350
https://www.openbsd.org/sparc.html - Discontinued
https://www.openbsd.org/sparc64.html - Supported
This is a big help because now I can put in production the SuperMicro E200-8D I bought to replace our older gateway.
https://www.openbsd.org/lyrics.html#61
That's usually my favourite part about new OpenBSD releases. :-)
https://www.rootbsd.net/
[1] https://github.com/eatonphil/linode_deploy_experimental
This is not a supported or convenient way to do your first OpenBSD install. Having a serial console is not necessary, but recommended (in particular, don't forget to configure <real-hw-interface>0, not the em0 that qemu is likely to offer you.) That said, I've done this before on some Hetzner serverauction (bare-metal) box, and the procedure worked fine (as one would expect.)
(Of course, you can run into hardware that OpenBSD doesn't support. Consult the man pages to find what is supported, or just try - server hardware is pretty likely to be supported.)
It's not just kernel bundled with a bunch of tools/programs which sort of seem to work together, but not in the same manor. Even FreeBSD have sometimes left me with the impression that the developers don't care about style and just import tools or subsystems at leave it at that, rather than making it feel like it belongs.
Both are valid, and result in very different operating systems. These days most of my work can be fit into the OpenBSD envelope, which makes me feel especially good.
ZFS is large and complicated. http://www.tedunangst.com/flak/post/ZFS-on-OpenBSD
DTrace would be nice to have, but I believe there are CDDL license concerns.
Jails are a way of isolating services so that they cannot do (much) damage to the system in the event they are compromised. The closest alternative in OpenBSD is probably pledge(2), which allows a program to voluntarily renounce the ability to invoke a set of syscalls. There is also chroot if all you need is filesystem virtualization.
MAC can be complicated to implement. This comment explained things very well: https://news.ycombinator.com/item?id=8893749
> OpenBSD doesn't support a MAC framework because they believe the best approach to security is correctness, rather than trying to achieve security by adding features which results in more complexity, making it more difficult to ensure correctness. A common mistake people make is thinking that OpenBSD's primary goal is security; their primary goal is correctness. This just happens to result in better security more often than not.
Linux compat is a similar story. OpenBSD dropped it in the 6.0 release due to complexity and security concerns.
I don't know a whole lot about CloudABI.
pledge is more similar to Capsicum. It is simpler to implement in some programs, sure, but:
1) I don't like how pledge just kills the program. Rude. Capsicum refuses the offending operation.
2) Capsicum has an absolutely brilliant feature for directory access — you just open() a file descriptor to a directory, then you cap_enter()… and in the sandbox mode you can use openat() to open files below that directory! This is just so clever. Meanwhile pledge promised a simple directory whitelist option that is STILL NOT IMPLEMENTED :(
CloudABI is a portable ABI that can be described as POSIX plus Capsicum minus anything incompatible with Capsicum. So CloudABI programs start already in capability mode, expecting necessary file descriptors to be already open (there's a launcher tool for that). You can just run CloudABI binaries unmodified on several operating systems and they are always sandboxed, they have no way to access anything you didn't pass to them. CloudABI is out-of-the-box supported on FreeBSD, there are kernel patches for NetBSD and Linux, and a user-mode syscall translator for macOS. https://nuxi.nl/cloudabi/
* https://www.freebsdnews.com/2016/01/27/zfs-boot-environment-...
I completely understand why these thing aren't being done, but not doing them mean that something will remain a little out of place.
But then FreeBSD itself lacks ACLs on tmpfs, EAs on ZFS, and SO_PEERCRED; and moreover OpenBSD does have wscons.
Yeah, SO_PEERCRED, I remember that one. The sway Wayland compositor relies on it to authenticate privileged programs (desktop bars, screensavers, screenshot tools etc.) When I was porting sway, that really annoyed me.
What are EAs?
And Postgres 9.6 in packages. Today is a good day
http://www.nmedia.net/nsh/
[edit] D'oh, for some reason I read "like pfsense" but missed "for openbsd."
So, you could run an HTTPS site, with a Perl fastCGI site, sending emails, all out of Base
Plus you get privsep'd X (xenocara)
https://wiki.ubuntu.com/X/Rootless
Also interesting is that support for rootless (at least in Arch) depends on, or perhaps was facilitated by systemd:
https://wiki.archlinux.org/index.php/Xorg#Rootless_Xorg_.28v...
I don't pay as close attention to Linux developments as I should these days!