From what I see, it is sort of a workaround to allow the OS to stay clean, but it does way more than that. It can reduce risk when upgrading firmware packages, filter out malicious versions of firmware, prevent upstream tampering or new backdoors, and less management effort. The jail’s room might can be expanded further, since nowadays we can get NOR flash larger than 32M, makes shipping firmware with BIOS pretty easy. It has potential.
I think if firmware jail keeps receiving attention from Purism, it might make Purism’s computers eventually having a extra edge against all other competitors on market, since nobody else cares about things happening in firmware. I have encountered multiple people asking me to fix their problematic wifi, and a good part of them were caused by updates. For example, Windows Update will download drivers and firmware that is not compatible. The idea of a computer that is resistant against problematic firmware install is alluring enough for me, all they need to do is to advertise.
I view firmware jail as a sad compromise that increases the executable binary blobs on a system, and I hope Purism eliminates it in the future, but thanks for offering a silver lining
I get your point, but what we can do is only to look on the bright side.
You can’t imagine that I check h-node.org every month since five years ago, only to find there’s barely any new WiFi device show up over there. Only replicas of same models, or fake/wrong ones. The somehow inspiring rtl8812au series are NOT libre and contains blob disguised as code.
Libre WiFi is close to death, and I’m just glad that Purism is the one who actually stepped a little further in this area, that’s why I don’t criticize them.
Not really. WiFi is complicated enough that there is always firmware (and nearly always a blob). It is just a question of where it permanently resides i.e. solely in the peripheral device, solely on the host computer’s disk, in a jail, somewhere else.
The problem is not the jail per se but obviously the fact that the WiFi firmware is a blob (no matter where it resides).
In my opinion, there’s little difference between somebody giving you a bad firmware package as a regular file vs. as a RO squashfs filesystem on RO flash memory (and, then, temporarily in a RAM fs). The term “Jail” is, IMO, simply a marketing distraction. Remember, there is already a mechanism (fwupd) to validate firmware signatures before updating firmware.
It depends on your threat model / what you consider to be “bad”.
If “bad” means blackbox / you don’t want to have to trust the manufacturer or anyone who can coerce the manufacturer (as it would include for most participants) then manufacturer firmware signatures buy you absolutely nothing.
But, sure, if you download firmware from some random dodgy third party web site then a signature is useful.
A file on disk is somewhat easier to tamper with after you receive the file, even if you did validate the signature.
The example I given is from multiple scenarios, not just a “someone is trying to harm YOU” event.
upgrading firmware packages
This one should be obvious. A failed/incomplete upgrade of firmware might leave a broken firmware, render your device unusable, and in worst case, you lose your access to Internet due to this. The jail is not affected by this, since it won’t be affected by OS software update.
filter out malicious versions of firmware
I admit this one is a little tricky, and this requires Purism to check that firmware thoroughly to achieve this. But at least they don’t have to check every version, just each version they wish to ship, which is easier to achieve. This is just better than than just blindly fetching a version online and use it, and Purism and us can regain some control. But still, we have no choice against the blobs, ar9170 series also have blob, just that it’s burnt on-board like those 4G modems.
prevent upstream tampering or new backdoors
This one should be pretty easy to explain. If the upstream is polluted by someone, or a new backdoor is added in newer versions, you are free of them. With the firmware burned onto NOR flash, no one but Purism can update that firmware. Needless to say, it is not affected by OS updates, and users have no urge to update it either. Purism can also provide extensive reason when it’s necessary to update the firmware.
that’s not true. Since it is flash, you can flash it. It is a lot more difficult to do than apt ... and a lot more protected against accidental or malicious change but change is still possible. Worst case, if you temporarily lose custody of your device, a malicious party can use an external flash chip programmer and/or replace the flash chip.
As an example, where let’s say you trust the manufacturer and all firmware versions from the manufacturer are digitally signed, even with enforcement within the peripheral device … let’s say version N has a serious vulnerability and version N+1 fixes that vulnerability. You flash N+1 on your own advice. A malicious party with access to your device can downgrade you to version N, thus reinstating the vulnerability.
The “firmware” I meant was WiFi firmware, not the entire Pureboot (which is motherboard firmware). I believe this might brought some confusion.
I’m pretty sure there are many people who knows how to deal with Pureboot, since it is a public product, and marketed “security” and “privacy”. But changing the WiFi and other peripheral device firmware bundled inside the firmware jail? Why? Especially when they got your physical device?
Imo, WiFi vulnerabilities are for wireless attacks, and the point is to eavesdrop or intervene the wireless connection. If one wants to utilize a vulnerability in WiFi firmware, all they need to know is your firmware version, and further, the Purism’s version. If they got your device physically, they either want your data, or want you away from your data. Vulnerabilities within Pureboot itself and hard drive firmware is more important in this scenario.
Indeed. If the attacker has temporary custody of your device, there may well be easier attacks - but this topic is about the considerations relating specifically to the firmware jail.
But then maybe everything that is on the hard disk is directly protected by Pureboot, so attacking peripheral firmware in the firmware jail is one of the few available vectors.
You would hope that all traffic is encrypted before presentation to the WiFi peripheral (as well as being encrypted within the WiFi layer) so that even a compromised WiFi peripheral cannot eavesdrop on payload content (only metadata and traffic analysis and the like).
But I was imagining an even more serious vulnerability (e.g. remote code execution vulnerability within the WiFi peripheral - and by definition WiFi and cellular are more vulnerable to remote attack than other peripherals) so that all bets are off as to what the peripheral might be doing against you after compromise.
I’m thinking of the case where the Wi-Fi card uses a libre driver that ships with Linux. Without the jail, PureOS devices could essentially only use such Wi-Fi cards, since others wouldn’t work. Using those cards would mean less secret executable blobs, at least in terms of Wi-Fi drivers, since the libre drivers are being used.
Depends what you mean by “installation”. Installation on the host computer? Or loading into the peripheral device (typically at boot time)?
Of course enforced signature is fundamentally yucky in an open source environment because it means you can’t make even the slightest intentional and legitimate change to the blob. So you are giving up essential liberty to purchase a little security, to misquote Benjamin Franklin.
In practice, that’s not true. As a user of a distro that does routinely update firmware (via apt), any upstream compromise would be almost immediate on my computers (badness) whereas firmware in the jail is harder to update, and not automatic, and the delay in getting the update in this scenario would be a good thing not a bad thing because the compromise would be discovered on someone else’s computer.
But, yes, let’s say a backdoor in a blob that lurks for a few years before showing itself in any way then, yes, new computers shipped out via Purism may well ship the backdoor.
afaik, the cards match your demand are generally limited to a group of old AR9271 series chips and a few old realtek chips, according to h-node.org. These chips are decade old, and uses older WiFi versions. The decision of using these outdated chips might be a security issue itself. And they are also slow, the fastest variant is AR9380, which can reach 450M (50mb/s), but it is usually a mini-pcie card, unfit for laptops. AR9565 is the only variant available in M.2 format that has 5Ghz support, but the speed is 150M (19mb/s).
I can live with those speeds. I’d rather not have the jail. Unfortunately, Wi-Fi is not a very free space, including many patents covering the standards themselves, so freedom-respecting devices may have to make serious sacrifices in terms of performance. I would rather that Purism keep to its strict focus on freedom instead of trying to make compromises like firmware jail, LibremOS, or Librem 11 to appeal to peoples’ other desires.
You still missed my point. I was talking about the firmware jail’s potential, not it’s current shape. I’m talking about how it can be, and you are trying to prove its current state is useless and insecure, this won’t go anywhere. Simply put, the entire “hardware support for libre distros” situation haven’t changed for decades, and isn’t likely to change anyway. The jail does not work if you switched the WiFi card, if you remove it, then there’s no related security issues. Just be reminded that using old ar9170 series WiFi card also means severe vulnerability: it also has a proprietary firmware burnt on-board, and haven’t been updates for decades. An experienced attacker can analyze your local WiFi signal, and utilize the weakness of old protocols and standards.
Firmware jail at current state is simply an awkward workaround to support some free software idealism, and everyone would agree with this. If you are just trying to prove it’s uselessness, well fair enough. I’m not going to convince you anyway.
The jail is completely optional, actually. You can build a custom version with the jail option off, and the blob removed. Or, just remove or replace the Intel AX200 with a AR9170 one. Just be reminded that AR9170 series card also has on-board firmware, and it has not been updated for decades, which means severe potential vulnerability.
It’s already a proprietary blob. Proprietary blobs aren’t part of a Free environment.
The Firmware Jail does not do anything in regard to security IMO. All it does it put proprietary firmware in RO conditions, when the standard solution (check signatures) is just as good. It doesn’t hide the fact that the real issue is that it’s proprietary.
As Benjamin Franklin also didn’t say: “It’s just putting lipstick on a pig”. Benjamin Franklin, however, did say: “You can’t make a silk purse from a sow’s ear” … which is good enough for this case.
You’re basically saying that “Purism is slower than Debian” is a security feature. That’s a rationalization I hadn’t heard before.
And I just don’t think that this is true. In terms of “integrity of firmware”, this doesn’t do anything more than the current tech of verifying signatures. The issue is that the firmware is proprietary, so you never know what you have and/or whether you can trust your firmware provider.
