This week we'll be talking with Ryan Lortie and Baptiste Daroussin about GNOME on BSD. Upstream development is finally treating the BSDs as a first class citizen, so we'll hear about how the recent porting efforts have been since.
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 doWhen using tame, programs will switch to a "restricted-service operating mode," limiting them to only the things they actually need to doAs 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, networkingRestrictions 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 tooCombined with a myriad of memory protections, tight privilege separation and (above all else) good coding practices, tame should further harden the OpenBSD security fortressFurther 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 upThis docker is "the real thing," and isn’t using a virtual machine as the backend - as such, it has some limitationsThe FreeBSD wiki has a page detailing how it works in general, as well as more info about those limitationsWhen 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 devThe version included in the base system was much smaller than the latest current version used elsewhere, but was based on older codeSome 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 compactThere 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 thereYou can check out the code now if you're interestedCommand usage and config syntax seem pretty straightforwardMore 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 seeThere 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 moreThe 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 unstableAnother 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 wellSome 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 moreAt least one user suggested better "marketing" for FreeBSD, with more advocacy and (hopefully) more business adoptionThat 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 nowMaybe 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 lostThere's an optional read-write partition as well, used for any persistent changes you want to makeYou 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 othersAfter looking at all the different choices, the author of this blog post eventually settled on iocage for the jobThe post walks you through the basic configuration and usage of iocage for creating managing jailsIf 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 CPUsThese GPUs are primarily used in the newer Atom CPUs and offer much better performance than the older onesA git branch was created to hold the fixes for now while the last remaining bugs get fixedFully-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) themHe 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 togetherOne big benefit is that WIP code gets tested much faster (and bugs get fixed early on)***
Feedback/Questions
Matthew writes inChris writes inAnonymous writes inBill writes in***
View all episodes
