12 March 2016

Fruit, Spooks, and Consumers: Oh My!

Okay, this is going to be my one and only monologue on the FBI / Apple encryption mess, so if you care about this subject at all pay some f***ing attention, please.

All of the talking heads are working in overdrive, and politicians are lining up to take sides on the issue.  I've heard just about every argument imaginable on the subject of privacy, and whether or not the FBI should have the right to decrypt the phone.  The answer to that, for the curious, is "yes."  In particular, "yes, they have a valid court order."

Unfortunately, that question (and the answer) is also totally f***ing irrelevant.  Some people might then say, "oh, well, the real question is whether Apple should have to 'help' the FBI decrypt the phone."  That is a bit closer, but it still misses the heart of the issue.

At issue here is not encryption, or Apple's track record of helping the FBI (which they do have), or even whether or not "unbreakable" encryption should be lawful, but a decades-old battle over one of the most sacred rights that We the People are afforded by the United States Constitution.

The real issue here is the powers of court order and legislation over the protections of the First Amendment.



At issue here is the Freedom of Speech.  See, the US Supreme Court has found time and time again that the First Amendment not only allows people freedom of speech, but allows them the freedom to refrain from speaking.  That last bit is central to the current debate, so bear it in mind for the rest of this post, please.

As we know, the former part (the ability to speak) can be suspended in certain situations- the Supreme Court has upheld gag orders, for example, as necessary to protect due process- but the second part has heretofore typically been considered sacrosanct.  That is to say, for a long time, SCOTUS has upheld the idea that the First Amendment also protects people from being compelled to speak.  Certain exception do exist, including, for example, a purveyor of goods being required to provide factual information about those goods, provided that the provision of the information is not unduly burdensome; think, for example, of nutritional labeling on food packaging.

Now, where does freedom of speech (or lack thereof) come in to to play, here?  We're talking about software, right?  Well, Apple is expected to assert that code, and in particular its cryptographic signature delivered to iPhones with every OS update and app, should be considered speech.  The reasoning here is that the signature allowing software to be installed on iOS devices constitutes an endorsement of that software.  If that seems a bit far-fetched, it's worth nothing that there's already precedent for treating computer code as free speech; see Bernstein v. U.S. Department of Justice (1999).

Apple has argued, and will likely continue to argue, that they are being not only compelled to speech, which would be bad enough, but compelled to burdensome speech, i.e. tasking their internal personnel and resources to create something which does not currently exist, at potentially significant monetary cost, but then further "endorsing" that software by signing it, which carries the risk of very real damage to their reputation.

The various three-letter agencies of the U.S. federal government are hoping to get a court order supporting the idea that computer code is not protected speech.


This would, among other things, allow the Department of Justice to begin regulating computer programs as "arms" under ITAR again, thereby allowing it to be heavily export-controlled as it was from the Red Scare until the mid-90s*.  The most frightening implication, however, is that it would open the door to web content potentially no longer be considered protected speech.  Yes, you read that correctly- web content is invariably stored as some sort of code or markup, and it's a very short ride from "computer programs are not protected speech" to e.g. "HTML markup is not protected speech."  Goodbye, warrant canaries (a goal of the fed for some time now anyway).  This is not some new problem of the twenty-first century, nor is this about terrorism, or gun control, or human lives- this is just the latest play in an attempt by the U.S. federal government to whittle and chip away at the First Amendment.  They've been trying to do this very thing for at least thirty years.  It's also worth noting that there are dissenters on this idea, who think that Apple's argument is a non-starter.  To that, all I can say is, "we'll have to wait and see."

That's why it's so important for Apple, and other tech companies, to fight this all of the way to SCOTUS, if necessary.  A SCOTUS ruling supporting the idea that computer code is not protected speech, which is a very real possibility, would open a Pandora's box of new federal government powers in this twenty-first century, where technology is everywhere.

It's a very short ride from computer code not being considered protected speech, to the federal government being able to compel people to provide passwords, surrender private encryption keys, or even write entire programs for free.


THAT, ladies and gents, is why Apple is fighting, and I for one don't give a damn what the FBI has to say on the subject of national security.  If Apple loses this fight, We the People are one step farther away from being in control of our government, and one step closer to the government controlling us.

* Note that cryptographic software was explicitly removed from ITAR circa 1996 strictly as a legal maneuver to prevent a judgement from being issued in an ongoing case; Bernstein v. DoJ (1999) later invalidated the use of ITAR for computer code, but the ruling was by then moot anyway.  Until now.

28 February 2016

First Look at HardenedBSD

When it comes to operating system security in the traditional sense, FreeBSD has a strong track record (to say the least).  Having said that, there are several twenty-first-century exploit mitigation technologies that are woefully absent.  Chief among these, of course, is support for Address Space Layout Randomization (ASLR), which helps to reduce the risk of a whole host of vulnerabilities such as buffer overflow exploits and return-to-libc attacks.  There have also been various and sundry attempts to take on FreeBSD jails over the years, with varying degrees of success.

Though I can and do trust a well-configured FreeBSD system over other FOSS alternatives- for its ground-up, only-what-you-need approaches as much as any other reason- I'm also not about to turn my nose up at attempts to improve the situation.

Enter HardenedBSD, a fork of the FreeBSD code base that ports various PaX enhancements (such as as ASLR and W^X pages), and provides a few FreeBSD-specific improvements for items such as jails and procfs.  It's been called "grsecurity for FreeBSD" on more than one occasion.  The HardenedBSD projects seems ultimately to be interested in merging these protections into "vanilla" FreeBSD once they've matured and been well-tested by the community.

To that end, I decided to try HBSD on a mature and well-established FreeBSD workstation.  That was roughly two months ago now.  While I can say categorically that there are a few parts of HBSD that are "rough around the edges," on the whole it seems to be a very well-maintained and valuable contribution to the *BSD ecosystem.  Here's the synopsis of my conversation process (feel free to skip past the indented parts if you just want the closing summary):

First off, I decided to do an in-place conversion from "vanilla" FreeBSD 11.0-CURRENT to HardenedBSD 11.0-CURRENT.  This process is not documented anywhere, and your own mileage may vary.  Having said that, it went fairly well from my perspective. 
Since I was on ZFS, I began by setting a mountpoint of "none" on the filesystem containing my system source code, creating a new one with a mountpoint of /usr/src, and pulling the HardenedBSD source down to that.  ZFS deduplication left a total disk usage increase of a few megabytes, once all was said and done for the source code transfer.
The next step was to copy over my custom kernel config, merge in the HardenedBSD-specific items (I did enable ptrace protection), then build and boot into the HardenedBSD kernel.  This went precisely as expected, at least at first.  The early boot messages reflected the enabled security protections, and the system came up to multi-user.  Then came the first snag: the "non-hardened" PAM module for Kerberos didn't work, and failed all attempts.  Since I had the console and all vtys marked as insecure, I had to reboot single-user to log in. 
Naturally, this seemed like a good time to build world, as it seemed obvious that there must be a compatibility issue at work.  This proved to be the case, as a normal ZFS snapshot / make buildworld / mergemaster -p / make installworld / mergemaster followed by another reboot had me logging in with Kerberos again.  Miraculously, all of my out-of-tree kernel modules (namely the nvidia driver and pefs) apparently worked fine without being rebuilt, though I did rebuild them anyway for good measure. 
The final conversion step was to rebuild any ports with changed Makefile options, which I figured out quickly with a diff between the official FreeBSD ports tree and that maintained by HardenedBSD.  For the most part, these consisted of adding PIE support into Chromium, Firefox, and a few others.  HardenedBSD does have a binary package repo that works well, but I usually prefer to build from source anyway.  Sucker for punishment, I guess... 
X.org and SLiM worked out of the box, I logged in to MATE just fine, and tried to fire up the recently-rebuilt Firefox.  Nothing happened that I could see.  Here came the first real "gotcha."  HardenedBSD relies heavily on an in-house utility called secadm to control some of its more advanced functionality.  Though some broad configuration can be done with the usual sysctl mechanisms, secadm is used for e.g. exempting certain programs (ahem, Chromium and Firefox, again) from W^X protection. 
For whatever reason, I didn't get secadm with my installworld process.  Turns out that it's a port, including a kernel module and a userland tool.  Once I installed that, I tried to apply the exemptions recommended on the HBSD wiki for Firefox, Chrome, and Java.  Whoops again- the documentation on their wiki was out of date at the time (it's since been fixed) and didn't reflect a syntax change in their secadm tool's configuration file syntax.  I found an updated example here, fired it up, and voila!  I was off and running.

Two months later, and I've barely noticed the difference between HardenedBSD and stock FreeBSD.  As far as I can tell, that's a good thing.  There are a few extra steps needed in some places, however, and a few quirks of which to be aware:
  • Any file that is currently the subject of a secadm rule cannot be deleted or modified.  The rule must be temporarily removed to allow changes to the file.  It makes sense from a security perspective, but this led me to clearing out my secadm rule set when doing portupgrade runs, and then re-installing the rules using the provided rc script afterwards.
  • Care must be taken in jails, and in particular when using any of the non-W^X safe programs like the web browsers or Java in jails.  secadm is jail-aware, and any per-program exemptions from system protections are not carried from the host in to the jail.  These must be activated within the jail by having a secadm config file and enabling the appropriate rc script.
  • Linux binary compatibility works only if some or all of the PaX protections are disabled per-program or per-jail.  I haven't yet been able to find a reliable pattern.  If you have a small number of seldom-used Linux binaries, you'll probably be fine brute-forcing the secadm rules that work for them (as I've done), but if you rely heavily on many Linux binaries or full Linux jails in FreeBSD, you might want to hold off on HardenedBSD for now.
  • PEFS and HardenedBSD don't like eachother at the moment.  Filesystems will mount and key addition works fine, and the filesystem will behave fine for most normal usage, but e.g. attempts to execute scripts (bash, Python, Ruby, you name it) from within a PEFS mountpoint using "./" syntax will often trigger a kernel panic.  You can get around this by explicitly calling the interpreter first, e.g. "bash ./my-script" though that's a tough habit to remember.  Normal binaries work fine though.  I need to delve in to this, and file a patch or at least a PR with the HBSD folks soon (or perhaps the PEFS folks, as the case may be).
That's really it.  Though there are definitely a few small kinks to work out, I think that the HBSD team has done a remarkable job.  For going completely off-the-map on the in-place conversion, I had a remarkably smooth experience, and my own two months without serious problems suggest the HBSD has a bright future ahead.  You can, of course, always download the pre-built versions and go through the normal installation from scratch, but where's the fun in that?