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...
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…
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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).
- arm added to the list of archs where the setjmp(3) family of functions apply XOR cookies to stack and return-address values in the jmpbuf.
- bioctl(8) now uses bcrypt PBKDF to derive keys for crypto volumes.
- Partial UTF-8 line editing support for ksh(1) Vi input mode.
- UTF-8 support in column(1).
--
Edit: Reordered things a little and grouped things together for legibility
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).
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.
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.)
