This episode was brought to you by

Headlines

OpenBSD presents tame

• Theo de Raadt sent out an email detailing OpenBSD's new "tame" subsystem, written by Nicholas Marriott and himself, for restricting what processes can and can't do
• When using tame, programs will switch to a "restricted-service operating mode," limiting them to only the things they actually need to do
• As for the background: "Generally there are two models of operation. The first model requires a major rewrite of application software for effective use (ie. capsicum). The other model in common use lacks granularity, and allows or denies an operation throughout the entire lifetime of a process. As a result, they lack differentiation between program 'initialization' versus 'main servicing loop.' systrace had the same problem. My observation is that programs need a large variety of calls during initialization, but few in their main loops."
• Some initial categories of operation include: computation, memory management, read-write operations on file descriptors, opening of files and, of course, networking
• Restrictions can also be stacked further into the lifespan of the process, but removed abilities can never be regained (obviously)
• Anything that tries to access resources outside of its in-place limits gets terminated with a SIGKILL or, optionally, a SIGABRT (which can produce useful core dumps for investigation)
• Also included are 29 examples of userland programs that get additional protection with very minimal changes to the source - only 2 or 3 lines needing changed in the case of binaries like cat, ps, dmesg, etc.
• This is an initial work-in-progress version of tame, so there may be more improvements or further control options added before it hits a release (very specific access policies can sometimes backfire, however)
• The man page, also included in the mail, provides some specifics about how to integrate tame properly into your code (which, by design, was made very easy to do - making it simple means third party programs are more likely to actually use it)
• Kernel bits are in the tree now, with userland changes starting to trickle in too
• Combined with a myriad of memory protections, tight privilege separation and (above all else) good coding practices, tame should further harden the OpenBSD security fortress
• Further discussion can be found in the usual places you'd expect ***

Using Docker on FreeBSD

• With the experimental Docker port landing in FreeBSD a few weeks ago, some initial docs are starting to show up
• This docker is "the real thing," and isn’t using a virtual machine as the backend - as such, it has some limitations
• The FreeBSD wiki has a page detailing how it works in general, as well as more info about those limitations
• When running Linux containers, it will only work as well as the Linux ABI compat layer for your version of FreeBSD (11.0, or -CURRENT when we're recording this, is where all the action is for 64bit support)
• For users on 10.X, there's also a FreeBSD container available, which allows you to use Docker as a fancy jail manager (it uses the jail subsystem internally)
• Give it a try, let us know how you find it to be compared to other solutions ***

OpenBSD imports doas, removes sudo

• OpenBSD has included the ubiquitous "sudo" utility for many years now, and the current maintainer of sudo (Todd C. Miller) is also a long-time OpenBSD dev
• The version included in the base system was much smaller than the latest current version used elsewhere, but was based on older code
• Some internal discussion lead to the decision that sudo should probably be moved to ports now, where it can be updated easily and offer all the extra features that were missing in base (LDAP and whatnot)
• Ted Unangst conjured up with a rewritten utility to replace it in the base system, dubbed "do as," with the aim of being more simple and compact
• There were concerns that sudo was too big and too complicated, and a quick 'n' dirty check reveals that doas is around 350 lines of code, while sudo is around 10,000 - which would you rather have as a setuid root binary?
• After the initial import, a number of developers began reviewing and improving various bits here and there
• You can check out the code now if you're interested
• Command usage and config syntax seem pretty straightforward
• More discussion on HN ***

What would you like to see in FreeBSD

• Adrian Chadd started a reddit thread about areas in which FreeBSD could be improved, asking the community what they'd like to see
• There are over 200 comments that span a wide range of topics, so we'll just cover a few of the more popular requests - check the very long thread if you're interested in more
• The top comment says things don't "just work," citing failover link aggregation of LACP laggs, PPPoE issues, disorganized jail configuration options, unclear CARP configuration and userland dtrace being unstable
• Another common one was that there are three firewalls in the base system, with ipfilter and pf being kinda dead now - should they be removed, and more focus put into ipfw?
• Video drivers also came up frequently, with users hoping for better OpenGL support and support for newer graphics cards from Intel and AMD - similar comments were made about wireless chipsets as well
• Some other replies included more clarity with pkgng output, paying more attention to security issues, updating PF to match the one in OpenBSD, improved laptop support, a graphical installer, LibreSSL in base, more focus on embedded MIPS devices, binary packages with different config options, steam support and lots more
• At least one user suggested better "marketing" for FreeBSD, with more advocacy and (hopefully) more business adoption
• That one really applies to all the BSDs, and regular users (that's you listening to this) can help make it happen for whichever ones you use right now
• Maybe Adrian can singlehandedly do all the work and make all the users happy ***

Interview - Ryan Lortie & Baptiste Daroussin

Porting the latest GNOME code to FreeBSD

News Roundup

Introducing resflash

• If you haven't heard of resflash before, it's "a tool for building OpenBSD images for embedded and cloud environments in a programmatic, reproducible way"
• One of the major benefits to images like this is the read-only filesystem, so there's no possibility of filesystem corruption if power is lost
• There's an optional read-write partition as well, used for any persistent changes you want to make
• You can check out the source code on Github or read the main site for more info ***

Jails with iocage

• There are a growing number of FreeBSD jail management utilities: ezjail, cbsd, warden and a few others
• After looking at all the different choices, the author of this blog post eventually settled on iocage for the job
• The post walks you through the basic configuration and usage of iocage for creating managing jails
• If you've been unhappy with ezjail or some of the others, iocage might be worth giving a try instead (it also has really good ZFS integration) ***

DragonFly GPU improvements

• DragonFlyBSD continues to up their graphics game, this time with Intel's ValleyView series of CPUs
• These GPUs are primarily used in the newer Atom CPUs and offer much better performance than the older ones
• A git branch was created to hold the fixes for now while the last remaining bugs get fixed
• Fully-accelerated Broadwell support and an update to newer DRM code are also available in the git branch, and will be merged to the main tree after some testing ***

Branchless development

• Ted Unangst has a new blog post up, talking about software branches and the effects of having (or not having) them
• He covers integrating and merging code, and the versioning problems that can happen with multiple people contributing at once
• "For an open source project, branching is counter intuitively antisocial. For instance, I usually tell people I’m running OpenBSD, but that’s kind of a lie. I’m actually running teduBSD, which is like OpenBSD but has some changes to make it even better. Of course, you can’t have teduBSD because I’m selfish. I’m also lazy, and only inclined to make my changes work for me, not everyone else."
• The solution, according to him, is bringing all the code the developers are using closer together
• One big benefit is that WIP code gets tested much faster (and bugs get fixed early on) ***

Feedback/Questions

• Matthew writes in
• Chris writes in
• Anonymous writes in
• Bill writes in ***