OpenBSD Journal

g2k16 Hackathon Report: Ted Unangst on doas, signify, code removal

Contributed by tj on from the sign-my-cd dept.

Next in our series of g2k16 hackathon reports is Ted Unangst, who writes:

This was my second trip to Cambridge, after a whirlwind tour during a EuroBSDCon past. Very happy to return. There's some really old stuff here!

There are rumors and rumbles about changes coming to the way OpenBSD configures network interfaces, which seems likely to trickle down to affecting rebound. Hopefully, this will help pull rebound out of limbo where it's currently stuck waiting for a good integration story. In the meantime, I decided to spruce it up with some fancier minimum TTL caching.

For some time, users and other developers have been asking me about adding timeout code to doas. I didn't want to complicate the core code however. There's been a crazy idea for some time to add something like ssh key support directly to BSD auth, which would then let you use ssh-agent to remember a key for use with doas invocations. Just describing how it would work is difficult.

However, Henning approached me and proposed an entirely different solution I'd never thought about. The timeout could be a property of the terminal itself. This turns out to be very easy to implement. A few dozen lines of kernel code adds support for the ioctl() commands necessary to set and check whether the user has recently authenticated. Another dozen lines in doas are all that's necessary to use this feature. The result is authorization persistence that's directly attached to the user session and can't be forged or manipulated. I'm very happy with the result, all because we finally got in a room together to chat about ideas.

In other doas news, shortly before the hackathon I wrote a mini-doas that goes into the installer and allows some of the more dangerous network operations to run with reduced privileges. Robert did the work, so that's not my story, but I was able to answer a few questions as well.

A little while ago, Theo added support to randomize the symbols in libc for each reboot. I fooled around a bit wtih a similar change to the kernel build process. The challenging part is that the kernel is not designed to be relocatble, so some symbols must appear in a certain order, and there are magic sections and addresses embedded within. They need to be pulled out into a separate file that doesn't go into the random list. Let's just say there are more of them than I first suspected.

To celebrate the release of 6.0, I finally retired the sparc port. Multiple architectures help keep unwanted assumptions from creeping into the codebase. Unfortunately, sparc machines are all rather slow by today's standards, and the sparc64 architecture is equally good at detecting problematic code. sparc hardware had fallen into disuse among developers, such that there wasn't anybody left to even do the builds for release. Only platforms which get run are good bug detectors. The sparc port will always have an important place in OpenBSD history, just not its future.

Marc redesigned the way in which packages are signed, moving the signature from inside the gzipped tar archive to outside. This code was easy to integrate into signify, but first I had to refactor a few functions. I'm sure Marc will have more to say about that, but it's always fun to go poke about in a codebase which I thought was finished.

We also decided to use SHA512/256 hashes for this, which combine the faster performance of SHA512 on 64-bit platforms (important for large files) with the smaller hashes of SHA256 (also important for large gzips with lots of chunks). I've wanted to add support for this to libc for a while now, but it never became urgent without a use case. Now that it's in libc, maybe more people can find a use for it.

In another line of attack on dangerous gzip files, I also refactored the gzip decompressor to allow the internal function to operate via a pipe with a forked child. Currently, gzip must retain some more privileges than we'd like during the critical zlib inflate stage because when finished it still needs to chown() the output file. Also, there may be multiple files specified in a single invocation. With these changes, a malicious file can send bad data over the pipe, but it will only be able to corrupt its own output file, not any other files on disk.

Thanks for the report, Ted!

(Comments are closed)


Comments
  1. By Anonymous Coward (118.20.98.73) on

    And he has a nice article to introduce doas
    http://www.tedunangst.com/flak/post/doas-mastery

    Comments
    1. By Sebastian Rother (78.42.111.136) on

      > And he has a nice article to introduce doas
      > http://www.tedunangst.com/flak/post/doas-mastery

      Awesome! :-)

  2. By Jo (93.128.226.138) on

    Why not switching to BLAKE2b-256, if speed is important?

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]