The PF life

It’s only one-week away from BSDCan, both Allan and I are excited to meet some of you in person! However, the show keeps on

This episode was brought to you by

Headlines

dotSecurity 2016 - Theo de Raadt - Privilege Separation and Pledge

• Video
• Slides
• Interested in Privilege Separation and security in general? If so, then you are in for a treat, we have both the video and slides from Theo de Raadt at dotSecurity 2016.
• Specifically the the talk starts off looking at Pledge (no copyright issues with the pictures I hope??) and how their NTP daemon uses it.
• After going through some internals, Theo reveals that around 10% of programs “pledged” so far were found to be trying to do actions outside of their security scope.
• On the future-work side, they mention going back and looking at OpenSSH privilege separation next, as well as working with other OS’s that may want pledge support. ***

bhyve now supports UEFI GOP

• The log awaited UEFI GOP (Graphics Output Protocol) features has landed in bhyve
• This provides emulated graphics via an internal VNC server, allowing users to have full graphical access to the guest OS
• This allows installation of Windows guests without needing to create a modified ISO with an unattended installation script
• The code has not actually landed in FreeBSD head yet, but has been committed to a project branch
• Following a few simple commands, you can compile the new bhyve binary on your -CURRENT system and get started right away
• This feature is expected to be included in the upcoming FreeBSD 11.0
• This commit drop also brings with it:
  • XHCI -- an emulated usb tablet device that provides exact mouse positioning in supported OSs
  • PS2 mouse for fallback if the guest does not support XHCI (Windows 7)
  • PS2 keyboard
• “The code has been tested with Windows 7/8/8.1/10 and Server 2k12/2k16, Ubuntu 15.10, and FreeBSD 10.3/11-CURRENT”
• “For VNC clients, TightVNC, TigherVNC, and RealVNC (aka VNC Viewer) have been tested on various hosts. The OSX VNC client is known not to work.”
• The VNC server supports an optional ‘wait’ parameter, that causes the VM to not actually boot until the VNC client connects, allowing you to interrupt the boot process if need be
• Related user blog post
• SVN commit ***

zfsd lands in FreeBSD HEAD, in time for 11.0-RELEASE

• zfsd has been committed to FreeBSD -CURRENT in time to be included in FreeBSD 11.0
• zfsd is the missing piece required to make ‘hot spares’ work properly in FreeBSD ZFS
• “zfsd attempts to resolve ZFS faults that the kernel can't resolve by itself. It listens to devctl(4) events, which is how the kernel notifies of events such as I/O errors and disk removals. Zfsd attempts to resolve these faults by activating or deactivating hotspares and onlining offline vdevs.”
• “The administrator never interacts with zfsd directly. Instead, he controls its behavior indirectly through zpool configuration. There are two ways to influence zfsd: assigning hotspares and setting pool properties. Currently, only the autoreplace property has any effect. See zpool(8) for details.”
• So, what example does it do?
• Device Removal: “When a leaf vdev disappears, zfsd will activate any available hotspare.”
• Device Arrival: “When a new GEOM device appears, zfsd will attempt to read its ZFS label, if any. If it matches a previously removed vdev on an active pool, zfsd will online it. Once resilvering completes, any active hotspare will detach automatically.”
• So if you disconnect a drive, then reconnect it, it will automatically be brought back online. Since ZFS is smart, the resilver will only have to copy data that has changed since the device went offline.
• “If the new device has no ZFS label but its physical path matches the physical path of a previously removed vdev on an active pool, and that pool has the autoreplace property set, then zfsd will replace the missing vdev with the newly arrived device. Once resilvering completes, any active hotspare will detach automatically.”
• If the new drive is in the same slot in your hot swap array as a failed device, it will be used as a replacement immediately.
• vdev degrade or fault events: “If a vdev becomes degraded or faulted, zfsd will activate any available hotspare. If a leaf vdev generates more than 50 I/O errors in a 60 second period, then zfsd will mark that vdev as FAULTED. zfs(4) will no longer issue any I/Os to it. zfsd will activate a hotspare if one is available.” Same for checksum errors.
• So if zfsd detects a drive is going bad, it brings the hotspare online before it is too late
• Spare addition: “If the system administrator adds a hotspare to a pool that is already degraded, zfsd will activate the spare.”
• Resilver complete: “zfsd will detach any hotspare once a permanent replacement finishes resilvering.”
• Physical path change: “If the physical path of an existing disk changes, zfsd will attempt to replace any missing disk with the same physical path, if its pool's autoreplace property is set.”
• In general, this tool means less reliance on the system administrator to keep the pool healthy ***

W^X now mandatory in OpenBSD

• We’ve talked a bit about W^X in the past. (Refresher: Memory being writable and executable at once)
• Well, this major security no-no is no-more on OpenBSD. Theo has committed a change which now prevents violations of this policy:

“W^X violations are no longer permitted by default. A kernel log message is generated, and mprotect/mmap return ENOTSUP. If the sysctl(8) flag kern.wxabort is set then a SIGABRT occurs instead, for gdb use or coredump creation.”

• There are a few cases where you may still need W^X, which Theo points out can be enabled on a file-system basis.

“W^X violating programs can be permitted on a ffs/nfs filesystem-basis, using the "wxallowed" mount option. One day far in the future upstream software developers will understand that W^X violations are a tremendously risky practice and that style of programming will be banished outright. Until then, we recommend most users need to use the wxallowed option on their /usr/local filesystem. At least your other filesystems don't permit such programs.”

• This is a great ability to grow, since now users can begin doing auditing of programs that violate this principle and making noise to upstream. ***

Interview - Kristof Provost - kp@freebsd.org @kprovst

• pf improvements on FreeBSD ***

News Roundup

GELI Support for the EFI Loader

• We’ve had Allan’s work to bring GELI support to the GPT / BIOS / ZFS loader for a while now, but the missing piece has been support for EFI.
• No longer, Eric McCorkle has posted a blog entry (with relevant github links) introducing us to his work to bring GELI encryption support to EFI.
• First the bad-news. This won’t make it into 11.0. (Maybe PC-BSD, TBD)
• Next he explains why this is more than just a new feature, but a re-factor of the EFI boot code:

I have already written extensively about my EFI refactoring here. The reason for undertaking this effort, however, was driven by GELI support. Early in my work on this, I had implemented a non-EFI “providers” framework in boot1 in order to support the notion of disk partitions that may contain sub-partitions.

• This was deeply unsatisfying to me for several reasons:
  • It implemented a lot of the same functionality that exists in the EFI framework.
  • It involved implementing a GPT partition driver to deal with partition tables inside GELI partitions (GPT detection and support is guaranteed by the EFI spec).
  • The interface between the EFI framework and the custom “providers” framework was awkward.
  • The driver was completely boot1-specific, and exporting it to something like GRUB probably involved a total rewrite.
  • Implementing it within loader was going to involve a lot of code duplication.
  • There was no obvious was to pass keys between boot1, loader, and the kernel.
• With the issues known, Eric seems pleased with the results of the conversion so far:
  • The GELI driver can be extracted from the FreeBSD codebase without too much trouble.
  • While I was unable to go all the way to the EFI driver model, the only blocker is the bcache code, and once that is resolved, we can have hotplug support in the boot loader!
  • The boot1 and loader codebases are now sharing all the backend drivers, and boot1 has been reduced to one very small source file.
• An interesting read, looking forward to playing with EFI more in the future! ***

Faces of FreeBSD 2016: Michael W. Lucas

• On this edition of “Faces of FreeBSD”, Michael W Lucas tells the story of how he got started with FreeBSD
• After an amusing re-telling of his childhood (The words “Purina Monkey Chow” were mentioned), he then tells us how he got into BSD.
• His being thrown into the project may sound familiar to many:

I came in at 11 PM one night and was told “The DNS administrator just got walked out the door. You’re the new lead DNS administrator. Make those servers work. Good luck.”

• From there (because he wanted more sleep), he began ripping out the systems that had been failing and waking him up at night. Good-bye UnixWare, Good-bye Solaris, hello BSD!
• A very amusing read, check it out! ***

High Availability with PostgreSQL on FreeBSD

• A talk by Sean Chittenden, who we interviewed previously on episode Episode 95
• Explains how to setup Multi Data Center High Availability for PostgreSQL using consul
• Goes into how consul works, how it does the election, the gossip protocol, etc
• The HA setup uses DNS Failover, and the pros and cons of that approach are discussed
• Then he walks through the implementation details, and example configuration ***

New FreeBSD i915 testing images

• Still need users to test the Linux Kernel 4.6 DRM update to FreeBSD’s graphics stack
• Download the test image and write it to a USB stick and boot from it
• It will not modify your installed system, it runs entirely off of the USB drive
• Allows you to test the updated drivers without having to install the development branch on your device
• you can tell them that ATI/AMD support will be coming shortly
• and that stability has been steadily improving
• and that I'll do another announcement as soon as I've had a chance to test the newest Xorg bits ***

Beastie Bits

• Comfortable on the CLI: Series Part 1
• FreeBSD Booting on the Netgate uFW, a smaller-than-a-raspberry-pi dual port firewall
• Picture of uFW
• uFW OpenSSL Benchmarks
  ***