diff --git a/content/apps/F-Droid Security Analysis.md b/content/apps/F-Droid Security Analysis.md index 541e021..6082bfb 100644 --- a/content/apps/F-Droid Security Analysis.md +++ b/content/apps/F-Droid Security Analysis.md @@ -1,6 +1,5 @@ --- title: "F-Droid Security Analysis" -date: 2022-01-02T21:28:31Z tags: ['software', 'android', 'security'] author: Wonderfall canonicalURL: https://wonderfall.dev/fdroid-issues @@ -155,7 +154,6 @@ In modern Android, the background restriction toggle is what really provides the Another example to illustrate the shortcomings of this approach would be the `QUERY_ALL_PACKAGES` low-level permission, which is referred to as the *query all packages* permission that "allows an app to see all installed packages". While this is somewhat correct, this can also be misleading: apps do not need `QUERY_ALL_PACKAGES` to list other apps within the same user profile. Even without this permission, some apps are visible automatically (visibility is restricted by default [since Android 11](https://developer.android.com/training/package-visibility)). If an app needs more visibility, it will declare a `` element in its manifest file: in other words, `QUERY_ALL_PACKAGES` is only one way to achieve visibility. Again, this goes to show low-level manifest permissions are not intended to be interpreted as high-level permissions the user should fully comprehend. -Play Store for instance conveys the permissions in a way less misleading way: the main low-level permissions are first grouped in their high-level user-facing toggles, and the rest is shown under "Other". This permission list can only be accessed by taping "About this app" then "App permissions - See more" at the bottom of the page. Play Store will tell the app may request access to the following permissions: this kind of wording is more important than it seems. *Update: since July 2022, Play Store doesn't offer a way to display low-level permissions anymore.* Moreover, [Play Store restricts the use of highly invasive permissions](https://support.google.com/googleplay/android-developer/answer/9888170) such as `MANAGE_EXTERNAL_STORAGE` which allows apps to opt out of scoped storage if they can't work with [more privacy friendly approaches](https://developer.android.com/guide/topics/providers/document-provider) (like a file explorer). Apps that can't justify their use of this permission (which again has to be granted dynamically) may be removed from Play Store. This is where an app repository can actually be useful in their review process to protect end-users from installing poorly made apps that might compromise their privacy. Not that it matters much if these apps target very old API levels that are inclined to require invasive permissions in the first place... diff --git a/content/os/Docker and OCI Hardening.md b/content/os/Docker and OCI Hardening.md index b0c46d4..47fe297 100644 --- a/content/os/Docker and OCI Hardening.md +++ b/content/os/Docker and OCI Hardening.md @@ -1,6 +1,5 @@ --- title: "Docker and OCI Hardening" -date: 2022-03-30T21:23:12Z tags: ['operating systems', 'linux', 'container', 'security'] author: Wonderfall canonicalURL: https://wonderfall.dev/docker-hardening/ diff --git a/content/os/Securing OpenSSH with FIDO2.md b/content/os/Securing OpenSSH with FIDO2.md new file mode 100644 index 0000000..1efa480 --- /dev/null +++ b/content/os/Securing OpenSSH with FIDO2.md @@ -0,0 +1,74 @@ +--- +title: "Securing OpenSSH with FIDO2" +tags: ['operating systems', 'linux', 'security'] +author: Wonderfall +canonicalURL: https://wonderfall.dev/openssh-fido2/ +ShowCanonicalLink: true +--- + +Passwordless authentication with OpenSSH keys has been the *de facto* security standard for years. SSH keys are more robust since they're cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They're also easier to manage while enabling a form of decentralized authentication (it's easy and painless to revoke them). So, what's the next step? And more exactly, why would one need something even better? + + +## Why? + +The main problem with SSH keys is that they're not magic: they consist of a key pair, of which the private key is stored on your disk. You should be wary of various exfiltration attempts, depending on your theat model: + +- If your disk is not encrypted, any physical access could compromise your keys. +- If your private key isn't encrypted, malicious applications could compromise it. +- Even with both encrypted, malicious applications could register your keystrokes. + +All these attempts are particularly a thing on desktop platforms, because they don't have a proper sandboxing model. On Windows, non-UWP apps could likely have full access to your `.ssh` directory. On desktop Linux distributions, sandboxing is also lacking, and the situation is even worse if you're using X.org since it allows apps to spy on each other (and on your keyboard) by design. A first good step would be to only use SSH from a trusted & decently secure system. + +Another layer of defense would obviously be multi-factor authentification, or the fact that you're relying on a shared secret instead. We can use FIDO2 security keys for that. That way, even if your private key is compromised, the attacker needs physical access to your security key. TOTP is another common 2FA technique, but it's vulnerable to various attacks, and relies on the quality of the implementation on the server. + + +## How? + +Fortunately for us, [OpenSSH 8.2](https://www.openssh.com/txt/release-8.2) (released in February 2020) introduced native support for FIDO2/U2F. Most OpenSSH distributions should have the middleware set to use the `libfido2` library, including portable versions such as the one [for Win32](https://github.com/PowerShell/Win32-OpenSSH). + +Basically, `ssh-keygen -t ${key_type}-sk` will generate for us a token-backed key pair. The key types that are supported depend on your security key. Newer models should support both ECDSA-P256 (`ecdsa-sk`) and Ed25519 (`ed25519-sk`). If the latter is available, you should prefer it. + +### Client configuration +To get started: + +``` +ssh-keygen -t ed25519-sk +``` + +This will generate a `id_ed25519_sk` private key and a `id_ed25519_sk.pub` public key in `.ssh`. These are defaults, but you can change them if you want. We will call this key pair a "handle", because they're not sufficient by themselves to derive the real secret (as you guessed it, the FIDO2 token is needed). `ssh-keygen` should ask you to touch the key, and enter the PIN prior to that if you did set one (you probably should). + +You can also generate a **resident key** (referred to as *discoverable credential* in the WebAuthn specification): + +``` +ssh-keygen -t ed25519-sk -O resident -O application=ssh:user1 +``` + +As you can see, a few options must be specified: + +- `-O resident` will tell `ssh-keygen` to generate a resident key, meaning that the private "handle" key will also be stored on the security key itself. This has security implications, but you may want that to move seamlessly between different computers. In that case, you should absolutely protect your key with a PIN beforehand. +- `-O application=ssh:` is necessary to instruct that the resident key will use a particular slot, because the security key will have to index the resident keys (by default, they use `ssh:` with an empty user ID). If this is not specificed, the next key generation might overwrite the previous one. +- `-O verify-required` is optional but instructs that a PIN is required to generate/access the key. + +Resident keys can be retrieved using `ssh-keygen -K` or `ssh-add -K` if you don't want to write them to the disk. + +### Server configuration +Next, transfer your public key over to the server (granted you have already access to it with a regular key pair): + +``` +ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub user@server.domain.tld +``` + +*Ta-da!* But one last thing: we need to make sure the server supports this public key format in `sshd_config`: + +``` +PubkeyAcceptedKeyTypes ssh-ed25519,sk-ssh-ed25519@openssh.com +``` + +Adding `sk-ssh-ed25519@openssh.com` to `PubkeyAcceptedKeyTypes` should suffice. It's best practice to only use the cryptographic primitives that you need, and hopefully ones that are also modern. This isn't a full-on SSH hardening guide, but you should take a look at the [configuration file GrapheneOS uses](https://github.com/GrapheneOS/infrastructure/blob/main/sshd_config) for their servers to give you an idea on a few good practices. + +Restart the `sshd` service and try to connect to your server using your key handle (by passing `-i ~/.ssh/id_ed25519_sk` to `ssh` for instance). If that works for you (your FIDO2 security key should be needed to derive the real secret), feel free to remove your previous keys from `.ssh/authorized_keys` on your server. + +## That's cool, right? +If you don't have a security key, you can buy one from [YubiKey](https://www.yubico.com/fr/store/) (I'm very happy with my 5C NFC by the way), [Nitrokey](https://www.nitrokey.com/), [SoloKeys](https://solokeys.com/) or [OnlyKey](https://onlykey.io/) (to name a few). If you have an Android device with a hardware security module (HSM), such as the Google Pixels equipped with Titan M (Pixel 3+), you could even use them as bluetooth security keys. + +*No reason to miss out on the party if you can afford it!* \ No newline at end of file diff --git a/external-blogs.sh b/external-blogs.sh index cbc8e85..dabc4fd 100755 --- a/external-blogs.sh +++ b/external-blogs.sh @@ -4,7 +4,8 @@ rm -rf './content/apps/F-Droid Security Analysis.md' curl https://raw.githubusercontent.com/Wonderfall/wonderfall.github.io/main/content/posts/fdroid-issues.md -o './content/apps/F-Droid Security Analysis.md' sed -i 's/title:.*/title: "F-Droid Security Analysis"/' './content/apps/F-Droid Security Analysis.md' -sed -i '/draft: false/d' './content/apps/F-Droid Security Analysis.md' +sed -i '/date:.*/d' './content/apps/F-Droid Security Analysis.md' +sed -i '/draft:.*/d' './content/apps/F-Droid Security Analysis.md' sed -i "s/tags:.*/tags: ['applications', 'android', 'security']/" './content/apps/F-Droid Security Analysis.md' sed -i '/^tags:.*/a ShowCanonicalLink: true' './content/apps/F-Droid Security Analysis.md' sed -i '/^tags:.*/a canonicalURL: https://wonderfall.dev/fdroid-issues' './content/apps/F-Droid Security Analysis.md' @@ -14,8 +15,20 @@ sed -i '/^tags:.*/a author: Wonderfall' './content/apps/F-Droid Security Analysi rm -rf './content/os/Docker and OCI Hardening.md' curl https://raw.githubusercontent.com/Wonderfall/wonderfall.github.io/main/content/posts/docker-hardening.md -o './content/os/Docker and OCI Hardening.md' sed -i 's/title:.*/title: "Docker and OCI Hardening"/' './content/os/Docker and OCI Hardening.md' -sed -i '/draft: false/d' './content/os/Docker and OCI Hardening.md' +sed -i '/date:.*/d' './content/os/Docker and OCI Hardening.md' +sed -i '/draft:.*/d' './content/os/Docker and OCI Hardening.md' sed -i "s/tags:.*/tags: ['operating systems', 'linux', 'container', 'security']/" './content/os/Docker and OCI Hardening.md' sed -i '/^tags:.*/a ShowCanonicalLink: true' './content/os/Docker and OCI Hardening.md' sed -i '/^tags:.*/a canonicalURL: https://wonderfall.dev/docker-hardening/' './content/os/Docker and OCI Hardening.md' -sed -i '/^tags:.*/a author: Wonderfall' './content/os/Docker and OCI Hardening.md' \ No newline at end of file +sed -i '/^tags:.*/a author: Wonderfall' './content/os/Docker and OCI Hardening.md' + +#Securing OpenSSH with FIDO2 +rm -rf './content/os/Securing OpenSSH with FIDO2.md' +curl https://raw.githubusercontent.com/Wonderfall/wonderfall.github.io/main/content/posts/openssh-fido2.md -o './content/os/Securing OpenSSH with FIDO2.md' +sed -i 's/title:.*/title: "Securing OpenSSH with FIDO2"/' './content/os/Securing OpenSSH with FIDO2.md' +sed -i '/date:.*/d' './content/os/Securing OpenSSH with FIDO2.md' +sed -i '/draft:.*/d' './content/os/Securing OpenSSH with FIDO2.md' +sed -i "s/tags:.*/tags: ['operating systems', 'linux', 'security']/" './content/os/Securing OpenSSH with FIDO2.md' +sed -i '/^tags:.*/a ShowCanonicalLink: true' './content/os/Securing OpenSSH with FIDO2.md' +sed -i '/^tags:.*/a canonicalURL: https://wonderfall.dev/openssh-fido2/' './content/os/Securing OpenSSH with FIDO2.md' +sed -i '/^tags:.*/a author: Wonderfall' './content/os/Securing OpenSSH with FIDO2.md' \ No newline at end of file diff --git a/public/apps/f-droid-security-analysis/index.html b/public/apps/f-droid-security-analysis/index.html index 8d34ed6..86693fb 100644 --- a/public/apps/f-droid-security-analysis/index.html +++ b/public/apps/f-droid-security-analysis/index.html @@ -3,9 +3,9 @@ Before we start, a few things to keep in mind: The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else’s work.">
Home » Applications

F-Droid Security Analysis

January 2, 2022 · 26 min · 5392 words · Wonderfall | Suggest Changes +The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else’s work.">
Home » Applications

F-Droid Security Analysis

25 min · 5298 words · Wonderfall | Suggest Changes  | Originally published at wonderfall.dev
Table of Contents

F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider.

Before we start, a few things to keep in mind:

  • The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else’s work. I have respect for any work done in the name of good intentions. Likewise, please don’t misinterpret the intentions of this article.
  • You have your own reasons for using open-source or free/libre/whatever software which won’t be discussed here. A development model shouldn’t be an excuse for bad practices and shouldn’t lure you into believing that it can provide strong guarantees it cannot.
  • A lot of information in this article is sourced from official and trusted sources, but you’re welcome to do your own research.
  • These analyses do not account for threat models and personal preferences. As the author of this article, I’m only interested in facts and not ideologies.

This is not an in-depth security review, nor is it exhaustive.

1. The trusted party problem

To understand why this is a problem, you’ll have to understand a bit about F-Droid’s architecture, the things it does very differently from other app repositories, and the Android platform security model (some of the issues listed in this article are somewhat out of the scope of the OS security model, but the majority is).

Unlike other repositories, F-Droid signs all the apps in the main repository with its own signing keys (unique per app) at the exception of the very few reproducible builds. A signature is a mathematical scheme that guarantees the authenticity of the applications you download. Upon the installation of an app, Android pins the signature across the entire OS (including user profiles): that’s what we call a trust-on-first-use model since all subsequent updates of the app must have the corresponding signature to be installed.

Normally, the developer is supposed to sign their own app prior to its upload on a distribution channel, whether that is a website or a traditional repository (or both). You don’t have to trust the source (usually recommended by the developer) except for the first installation: future updates will have their authenticity cryptographically guaranteed. The issue with F-Droid is that all apps are signed by the same party (F-Droid) which is also not the developer. You’re now adding another party you’ll have to trust since you still have to trust the developer anyway, which isn’t ideal: the fewer parties, the better.

On the other hand, Play Store now manages the app signing keys too, as Play App Signing is required for app bundles which are required for new apps since August 2021. These signing keys can be uploaded or automatically generated, and are securely stored by Google Cloud Key Management Service. It should be noted that the developer still has to sign the app with an upload key so that Google can verify its authenticity before signing it with the app signing key. For apps created before August 2021 that may have not opted in Play App Signing yet, the developer still manages the private key and is responsible for its security, as a compromised private key can allow a third party to sign and distribute malicious code.

F-Droid requires that the source code of the app is exempt from any proprietary library or ad service, according to their inclusion policy. Usually, that means that some developers will have to maintain a slightly different version of their codebase that should comply with F-Droid’s requirements. Besides, their “quality control” offers close to no guarantees as having access to the source code doesn’t mean it can be easily proofread. Saying Play Store is filled with malicious apps is beyond the point: the false sense of security is a real issue. Users should not think of the F-Droid main repository as free of malicious apps, yet unfortunately many are inclined to believe this.

But… can’t I just trust F-Droid and be done with it?

You don’t have to take my word for it: they openly admit themselves it’s a very basic process relying on badness enumeration (this doesn’t work by the way) which consists in a few scripts scanning the code for proprietary blobs and known trackers. You are therefore not exempted from trusting upstream developers and it goes for any repository.

A tempting idea would be to compare F-Droid to the desktop Linux model where users trust their distribution maintainers out-of-the-box (this can be sane if you’re already trusting the OS anyway), but the desktop platform is intrinsically chaotic and heterogeneous for better and for worse. It really shouldn’t be compared to the Android platform in any way.

While we’ve seen that F-Droid controls the signing servers (much like Play App Signing), F-Droid also fully controls the build servers that run the disposable VMs used for building apps. And as of July 2022, their guest VM image officially runs a version of Debian which reached EOL. Undoubtedly, this raises questions about their whole infrastructure security.

How can you be sure that the app repository can be held to account for the code it delivers?

F-Droid’s answer, interesting yet largely unused, is build reproducibility. While deterministic builds are a neat idea in theory, it requires the developer to make their toolchain match with what F-Droid provides. It’s additional work on both ends sometimes resulting in apps severely lagging behind in updates, so reproducible builds are not as common as we would have wanted. It should be noted that reproducible builds in the main repository can be exclusively developer-signed.

Google’s approach is code transparency for app bundles, which is a simple idea addressing some of the concerns with Play App Signing. A JSON Web Token (JWT) signed by a key private to the developer is included in the app bundle before its upload to Play Store. This token contains a list of DEX files and native .so libraries and their hashes, allowing end-users to verify that the running code was built and signed by the app developer. Code transparency has known limitations, however: not all resources can be verified, and this verification can only be done manually since it’s not part of the Android platform itself (so requiring a code transparency file cannot be enforced by the OS right now). Despite its incompleteness, code transparency is still helpful, easy to implement, and thus something we should see more often as time goes by.

What about other app repositories such as Amazon?

To my current knowledge, the Amazon Appstore has always been wrapping APKs with their own code (including their own trackers), and this means they were effectively resigning submitted APKs.

If you understood correctly the information above, Google can’t do this for apps that haven’t opted in Play App Signing. As for apps concerned by Play App Signing, while Google could technically introduce their own code like Amazon, they wouldn’t do that without telling about it since this will be easily noticeable by the developer and more globally researchers. They have other means on the Android app development platform to do so. Believing they won’t do that based on this principle is not a strong guarantee, however: hence the above paragraph about code transparency for app bundles.

Huawei AppGallery seems to have a similar approach to Google, where submitted apps could be developer-signed, but newer apps will be resigned by Huawei.

2. Slow and irregular updates

Since you’re adding one more party to the mix, that party is now responsible for delivering proper builds of the app: it’s a common thing among traditional Linux distributions and their packaging system. They have to catch up with upstream on a regular basis, but very few do it well (Arch Linux comes to my mind). Others, like Debian, prefer making extensive downstream changes and delivering security fixes for a subset of vulnerabilities assigned to a CVE (yeah, it’s as bad as it sounds, but that’s another topic).

Not only does F-Droid require specific changes for the app to comply with its inclusion policy, which often leads to more maintenance work, it also has a rather strange way of triggering new builds. Part of its build process seems to be automated, which is the least you could expect. Now here’s the thing: app signing keys are on an air-gapped server (meaning it’s disconnected from any network, at least that’s what they claim: see their recommendations for reference), which forces an irregular update cycle where a human has to manually trigger the signing process. It is far from an ideal situation, and you may argue it’s the least to be expected since by entrusting all the signing keys to one party, you could also introduce a single point of failure. Should their system be compromised (whether from the inside or the outside), this could lead to serious security issues affecting plenty of users.

This is one of the main reasons why Signal refused to support the inclusion of a third-party build in the F-Droid official repository. While this GitHub issue is quite old, many points still hold true today.

Considering all this, and the fact that their build process is often broken using outdated tools, you have to expect far slower updates compared to a traditional distribution system. Slow updates mean that you will be exposed to security vulnerabilities more often than you should’ve been. It would be unwise to have a full browser updated through the F-Droid official repository, for instance. F-Droid third-party repositories somewhat mitigate the issue of slow updates since they can be managed directly by the developer. It isn’t ideal either as you will see below.

3. Low target API level (SDK) for client & apps

SDK stands for Software Development Kit and is the collection of software to build apps for a given platform. On Android, a higher SDK level means you’ll be able to make use of modern API levels of which each iteration brings security and privacy improvements. For instance, API level 31 makes use of all these improvements on Android 12.

As you may already know, Android has a strong sandboxing model where each application is sandboxed. You could say that an app compiled with the highest API level benefits from all the latest improvements brought to the app sandbox; as opposed to outdated apps compiled with older API levels, which have a weaker sandbox.

# b/35917228 - /proc/misc access
 # This will go away in a future Android release
 allow untrusted_app_25 proc_misc:file r_file_perms;
@@ -34,7 +34,7 @@ allow untrusted_app_25 proc_tty_drivers:file r_file_perms;
         </pin-set>
     </domain-config>
 </network-security-config>
-

To be fair, they’ve thought several times about adding certificate pinning to their client at least for the default repositories. Relics of preliminary work can even be found in their current codebase, but it’s unfortunate that they haven’t been able to find any working implementation so far. Given the overly complex nature of F-Droid, that’s largely understandable.

F-Droid also has a problem regarding the adoption of new signature schemes as they held out on the v1 signature scheme (which was horrible and deprecated since 2017) until they were forced by Android 11 requirements to support the newer v2/v3 schemes (v2 was introduced in Android 7.0). Quite frankly, this is straight-up bad, and signing APKs with GPG is no better considering how bad PGP and its reference implementation GPG are (even Debian is trying to move away from it). Ideally, F-Droid should fully move on to newer signature schemes, and should completely phase out the legacy signature schemes which are still being used for some apps and metadata.

5. Confusing UX

It is worth mentioning that their website has (for some reason) always been hosting an outdated APK of F-Droid, and this is still the case today, leading to many users wondering why they can’t install F-Droid on their secondary user profile (due to the downgrade prevention enforced by Android). “Stability” seems to be the main reason mentioned on their part, which doesn’t make sense: either your version isn’t ready to be published in a stable channel, or it is and new users should be able to access it easily.

F-Droid should enforce the approach of prefixing the package name of their alternate builds with org.f-droid for instance (or add a .fdroid suffix as some already have). Building and signing while reusing the package name (application ID) is bad practice as it causes signature verification errors when some users try to update/install these apps from other sources, even directly from the developer. That is again due to the security model of Android which enforces a signature check when installing app updates (or installing them again in a secondary user profile). Note that this is going to be an issue with Play App Signing as well, and developers are encouraged to follow this approach should they intend to distribute their apps through different distribution channels.

This results in a confusing user experience where it’s hard to keep track of who signs each app, and from which repository the app should be downloaded or updated.

6. Misleading permissions approach

F-Droid shows a list of the low-level permissions for each app: these low-level permissions are usually grouped in the standard high-level permissions (Location, Microphone, Camera, etc.) and special toggles (nearby Wi-Fi networks, Bluetooth devices, etc.) that are explicitly based on a type of sensitive data. While showing a list of low-level permissions could be useful information for a developer, it’s often a misleading and inaccurate approach for the end-user. Since Android 6, apps have to request the standard permissions at runtime and do not get them simply by being installed, so showing all the “under the hood” permissions without proper context is not useful and makes the permission model unnecessarily confusing.

F-Droid claims that these low-level permissions are relevant because they support Android 5.1+, meaning they support very outdated versions of Android where apps could have install-time permissions. Anyway, if a technical user wants to see all the manifest permissions for some reason, then they can access the app manifest pretty easily (in fact, exposing the raw manifest would be less misleading). But this is already beyond the scope of this article because anyone who cares about privacy and security wouldn’t run a 8 years old version of Android that has not received security updates for years.

To clear up confusion: even apps targeting an API level below 23 (Android 5.1 or older) do not have permissions granted at install time on modern Android, which instead displays a legacy permission grant dialog. Whether or not permissions are granted at install time does not just depend on the app’s targetSdkVersion. And even if this were the case, the OS package installer on modern Android would’ve been designed to show the requested permissions for those legacy apps.

For example, the low-level permission RECEIVE_BOOT_COMPLETED is referred to in F-Droid as the run at startup description, when in fact this permission is not needed to start at boot and just refers to a specific time broadcasted by the system once it finishes booting, and is not about background usage (though power usage may be a valid concern). To be fair, these short summaries used to be provided by the Android documentation years ago, but the permission model has drastically evolved since then and most of them aren’t accurate anymore.

Allows the app to have itself started as soon as the system has finished booting. This can make it take longer to start the phone and allow the app to slow down the overall phone by always running.

In modern Android, the background restriction toggle is what really provides the ability for apps to run in the background. Some low-level permissions don’t even have a security/privacy impact and shouldn’t be misinterpreted as having one. Anyhow, you can be sure that each dangerous low-level permission has a high-level representation that is disabled by default and needs to be granted dynamically to the app (by a toggle or explicit user consent in general).

Another example to illustrate the shortcomings of this approach would be the QUERY_ALL_PACKAGES low-level permission, which is referred to as the query all packages permission that “allows an app to see all installed packages”. While this is somewhat correct, this can also be misleading: apps do not need QUERY_ALL_PACKAGES to list other apps within the same user profile. Even without this permission, some apps are visible automatically (visibility is restricted by default since Android 11). If an app needs more visibility, it will declare a <queries> element in its manifest file: in other words, QUERY_ALL_PACKAGES is only one way to achieve visibility. Again, this goes to show low-level manifest permissions are not intended to be interpreted as high-level permissions the user should fully comprehend.

Play Store for instance conveys the permissions in a way less misleading way: the main low-level permissions are first grouped in their high-level user-facing toggles, and the rest is shown under “Other”. This permission list can only be accessed by taping “About this app” then “App permissions - See more” at the bottom of the page. Play Store will tell the app may request access to the following permissions: this kind of wording is more important than it seems. Update: since July 2022, Play Store doesn’t offer a way to display low-level permissions anymore.

Moreover, Play Store restricts the use of highly invasive permissions such as MANAGE_EXTERNAL_STORAGE which allows apps to opt out of scoped storage if they can’t work with more privacy friendly approaches (like a file explorer). Apps that can’t justify their use of this permission (which again has to be granted dynamically) may be removed from Play Store. This is where an app repository can actually be useful in their review process to protect end-users from installing poorly made apps that might compromise their privacy. Not that it matters much if these apps target very old API levels that are inclined to require invasive permissions in the first place…

Conclusion: what should you do?

So far, you have been presented with referenced facts that are easily verifiable. In the next part, I’ll allow myself to express my own thoughts and opinions. You’re free to disagree with them, but don’t let that overshadow the rest.

While some improvements could easily be made, I don’t think F-Droid is in an ideal situation to solve all of these issues because some of them are inherent flaws in their architecture. I’d also argue that their core philosophy is not aligned with some security principles expressed in this article. In any case, I can only wish for them to improve since they’re one of the most popular alternatives to commercial app repositories, and are therefore trusted by a large userbase.

F-Droid is often seen as the only way to get and support open-source apps: that is not the case. Sure, F-Droid could help you in finding FOSS apps that you wouldn’t otherwise have known existed. Many developers also publish their FOSS apps on the Play Store or their website directly. Most of the time, releases are available on GitHub, which is great since each GitHub releases page has an Atom feed. If downloading APKs from regular websites, you can use apksigner to validate the authenticity by comparing the certificate fingerprint against the fingerprint from another source (it wouldn’t matter otherwise).

This is how you may proceed to get the app certificate:

apksigner verify --print-certs --verbose myCoolApp.apk
+

To be fair, they’ve thought several times about adding certificate pinning to their client at least for the default repositories. Relics of preliminary work can even be found in their current codebase, but it’s unfortunate that they haven’t been able to find any working implementation so far. Given the overly complex nature of F-Droid, that’s largely understandable.

F-Droid also has a problem regarding the adoption of new signature schemes as they held out on the v1 signature scheme (which was horrible and deprecated since 2017) until they were forced by Android 11 requirements to support the newer v2/v3 schemes (v2 was introduced in Android 7.0). Quite frankly, this is straight-up bad, and signing APKs with GPG is no better considering how bad PGP and its reference implementation GPG are (even Debian is trying to move away from it). Ideally, F-Droid should fully move on to newer signature schemes, and should completely phase out the legacy signature schemes which are still being used for some apps and metadata.

5. Confusing UX

It is worth mentioning that their website has (for some reason) always been hosting an outdated APK of F-Droid, and this is still the case today, leading to many users wondering why they can’t install F-Droid on their secondary user profile (due to the downgrade prevention enforced by Android). “Stability” seems to be the main reason mentioned on their part, which doesn’t make sense: either your version isn’t ready to be published in a stable channel, or it is and new users should be able to access it easily.

F-Droid should enforce the approach of prefixing the package name of their alternate builds with org.f-droid for instance (or add a .fdroid suffix as some already have). Building and signing while reusing the package name (application ID) is bad practice as it causes signature verification errors when some users try to update/install these apps from other sources, even directly from the developer. That is again due to the security model of Android which enforces a signature check when installing app updates (or installing them again in a secondary user profile). Note that this is going to be an issue with Play App Signing as well, and developers are encouraged to follow this approach should they intend to distribute their apps through different distribution channels.

This results in a confusing user experience where it’s hard to keep track of who signs each app, and from which repository the app should be downloaded or updated.

6. Misleading permissions approach

F-Droid shows a list of the low-level permissions for each app: these low-level permissions are usually grouped in the standard high-level permissions (Location, Microphone, Camera, etc.) and special toggles (nearby Wi-Fi networks, Bluetooth devices, etc.) that are explicitly based on a type of sensitive data. While showing a list of low-level permissions could be useful information for a developer, it’s often a misleading and inaccurate approach for the end-user. Since Android 6, apps have to request the standard permissions at runtime and do not get them simply by being installed, so showing all the “under the hood” permissions without proper context is not useful and makes the permission model unnecessarily confusing.

F-Droid claims that these low-level permissions are relevant because they support Android 5.1+, meaning they support very outdated versions of Android where apps could have install-time permissions. Anyway, if a technical user wants to see all the manifest permissions for some reason, then they can access the app manifest pretty easily (in fact, exposing the raw manifest would be less misleading). But this is already beyond the scope of this article because anyone who cares about privacy and security wouldn’t run a 8 years old version of Android that has not received security updates for years.

To clear up confusion: even apps targeting an API level below 23 (Android 5.1 or older) do not have permissions granted at install time on modern Android, which instead displays a legacy permission grant dialog. Whether or not permissions are granted at install time does not just depend on the app’s targetSdkVersion. And even if this were the case, the OS package installer on modern Android would’ve been designed to show the requested permissions for those legacy apps.

For example, the low-level permission RECEIVE_BOOT_COMPLETED is referred to in F-Droid as the run at startup description, when in fact this permission is not needed to start at boot and just refers to a specific time broadcasted by the system once it finishes booting, and is not about background usage (though power usage may be a valid concern). To be fair, these short summaries used to be provided by the Android documentation years ago, but the permission model has drastically evolved since then and most of them aren’t accurate anymore.

Allows the app to have itself started as soon as the system has finished booting. This can make it take longer to start the phone and allow the app to slow down the overall phone by always running.

In modern Android, the background restriction toggle is what really provides the ability for apps to run in the background. Some low-level permissions don’t even have a security/privacy impact and shouldn’t be misinterpreted as having one. Anyhow, you can be sure that each dangerous low-level permission has a high-level representation that is disabled by default and needs to be granted dynamically to the app (by a toggle or explicit user consent in general).

Another example to illustrate the shortcomings of this approach would be the QUERY_ALL_PACKAGES low-level permission, which is referred to as the query all packages permission that “allows an app to see all installed packages”. While this is somewhat correct, this can also be misleading: apps do not need QUERY_ALL_PACKAGES to list other apps within the same user profile. Even without this permission, some apps are visible automatically (visibility is restricted by default since Android 11). If an app needs more visibility, it will declare a <queries> element in its manifest file: in other words, QUERY_ALL_PACKAGES is only one way to achieve visibility. Again, this goes to show low-level manifest permissions are not intended to be interpreted as high-level permissions the user should fully comprehend.

Moreover, Play Store restricts the use of highly invasive permissions such as MANAGE_EXTERNAL_STORAGE which allows apps to opt out of scoped storage if they can’t work with more privacy friendly approaches (like a file explorer). Apps that can’t justify their use of this permission (which again has to be granted dynamically) may be removed from Play Store. This is where an app repository can actually be useful in their review process to protect end-users from installing poorly made apps that might compromise their privacy. Not that it matters much if these apps target very old API levels that are inclined to require invasive permissions in the first place…

Conclusion: what should you do?

So far, you have been presented with referenced facts that are easily verifiable. In the next part, I’ll allow myself to express my own thoughts and opinions. You’re free to disagree with them, but don’t let that overshadow the rest.

While some improvements could easily be made, I don’t think F-Droid is in an ideal situation to solve all of these issues because some of them are inherent flaws in their architecture. I’d also argue that their core philosophy is not aligned with some security principles expressed in this article. In any case, I can only wish for them to improve since they’re one of the most popular alternatives to commercial app repositories, and are therefore trusted by a large userbase.

F-Droid is often seen as the only way to get and support open-source apps: that is not the case. Sure, F-Droid could help you in finding FOSS apps that you wouldn’t otherwise have known existed. Many developers also publish their FOSS apps on the Play Store or their website directly. Most of the time, releases are available on GitHub, which is great since each GitHub releases page has an Atom feed. If downloading APKs from regular websites, you can use apksigner to validate the authenticity by comparing the certificate fingerprint against the fingerprint from another source (it wouldn’t matter otherwise).

This is how you may proceed to get the app certificate:

apksigner verify --print-certs --verbose myCoolApp.apk

Also, as written above: the OS pins the app signature (for all profiles) upon installation, and enforces signature check for app updates. In practice, this means the source doesn’t matter as much after the initial installation.

For most people, I’d recommend just sticking with Play Store. Play Store isn’t quite flawless, but emphasises the adoption of modern security standards which in turn encourages better privacy practices; as strange as it may sound, Google is not always doing bad things in that regard.

Note: this article obviously can’t address all the flaws related to Play Store itself. Again, the main topic of this article is about F-Droid and should not be seen as an exhaustive comparison between different app repositories.

Should I really care?

It’s up to your threat model, and of course your personal preferences. Most likely, your phone won’t turn into a nuclear weapon if you install F-Droid on it - and this is far from the point that this article is trying to make. Still, I believe the information presented will be valuable for anyone who values a practical approach to privacy (rather than an ideological one). Such an approach is partially described below.

But there is more malware in Play Store! How can you say that it’s more secure?

As explained above, it doesn’t matter as you shouldn’t really rely on any quality control to be the sole guarantee that a software is free of malicious or exploitable code. Play Store and even the Apple App Store may have a considerable amount of malware because a full reverse-engineering of any uploaded app isn’t feasible realistically. However, they fulfill their role quite well, and that is all that is expected of them.

With Play App Signing being effectively enforced for new apps, isn’t Play Store as “flawed” as F-Droid?

I’ve seen this comment repeatedly, and it would be dismissing all the other points made in this article. Also, I strongly suggest that you carefully read the sections related to Play App Signing, and preferably the official documentation on this matter. It’s not a black and white question and there are many more nuances to it.

Aren’t open-source apps more secure? Doesn’t it make F-Droid safer?

You can still find and get your open-source apps elsewhere. And no, open-source apps aren’t necessarily more private or secure. Instead, you should rely on the strong security and privacy guarantees provided by a modern operating system with a robust sandboxing/permission model, namely modern Android, GrapheneOS and iOS. Pay close attention to the permissions you grant, and avoid legacy apps as they could require invasive permissions to run.

When it comes to trackers (this really comes up a lot), you shouldn’t believe in the flawed idea that you can enumerate all of them. The enumerating badness approach is known to be flawed in the security field, and the same applies to privacy. You shouldn’t believe that a random script can detect every single line of code that can be used for data exfiltration. Data exfiltration can be properly prevented in the first place by the permission model, which again denies access to sensitive data by default: this is a simple, yet rigorous and effective approach.

No app should be unnecessarily entrusted with any kind of permission. It is only if you deem it necessary that you should allow access to a type of data, and this access should be as fine-grained as possible. That’s the way the Android platform works (regular apps run in the explicit untrusted_app domain) and continues evolving. Contrary to some popular beliefs, usability and most productivity tasks can still be achieved in a secure and private way.

Isn’t Google evil? Isn’t Play Store spyware?

Some people tend to exaggerate the importance of Google in their threat model, at the cost of pragmatism and security/privacy good practices. Play Store isn’t spyware and can run unprivileged like it does on GrapheneOS (including with unattended updates support). On the vast majority of devices though, Google Play is a privileged app and a core part of the OS that provides low-level system modules. In that case, the trust issues involved with Play App Signing could be considered less important since Google Play is already trusted as a privileged component.

Play Store evidently has some privacy issues given it’s a proprietary service which requires an account (this cannot be circumvented), and Google services have a history of nagging users to enable privacy-invasive features. Again, some of these privacy issues can be mitigated by setting up the Play services compatibility layer from GrapheneOS which runs Play services and Play Store in the regular app sandbox (the untrusted_app domain). ProtonAOSP also shares that feature. This solution could very well be ported to other Android-based operating systems. If you want to go further, consider using a properly configured account with the least amount of personally indentifiable information possible (note that the phone number requirement appears to be region-dependent).

If you don’t have Play services installed, you can use a third-party Play Store client called Aurora Store. Aurora Store has some issues of its own, and some of them overlap in fact with F-Droid. Aurora Store somehow still requires the legacy storage permission, has yet to implement certificate pinning, has been known to sometimes retrieve wrong versions of apps, and distributed account tokens over cleartext HTTP until fairly recently; not that it matters much since tokens were designed to be shared between users, which is already concerning. I’d recommend against using the shared “anonymous” accounts feature: you should make your own throwaway account with minimal information.

You should also keep an eye on the great work GrapheneOS does on their future app repository. It will be a simple, secure, modern app repository for a curated list of high-quality apps, some of which will have their own builds (for instance, Signal still uses their original 1024-bits RSA key that has never been rotated since then). Inspired by this work, a GrapheneOS community member is developing a more generic app repository called Accrescent. Hopefully, we’ll see well-made alternatives like these flourish.

Thanks to the GrapheneOS community for proofreading this article. Bear in mind that these are not official recommendations from the GrapheneOS project.

Post-publication note: it’s unfortunate that the release of this article mostly triggered a negative response from the F-Droid team which prefers to dismiss this article on several occasions rather than bringing relevant counterpoints. Some of their core members are also involved in a harassment campaign towards projects and security researchers that do not share their views. While this article remains a technical one, there are definitely ethical concerns to take into consideration.

© 2022 PrivSec.dev Powered by Hugo & diff --git a/public/apps/index.html b/public/apps/index.html index a66440f..eaeb1d3 100644 --- a/public/apps/index.html +++ b/public/apps/index.html @@ -1,7 +1,7 @@ Applications | PrivSec.dev
Home

Applications

F-Droid Security Analysis

F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider. Before we start, a few things to keep in mind: -The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else’s work....

January 2, 2022 · 26 min · 5392 words · Wonderfall
© 2022 PrivSec.dev +The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else’s work....

25 min · 5298 words · Wonderfall
\ No newline at end of file diff --git a/public/apps/index.xml b/public/apps/index.xml index f177e6f..63e2458 100644 --- a/public/apps/index.xml +++ b/public/apps/index.xml @@ -4,12 +4,11 @@ Applications on PrivSec.dev https://privsec.dev/apps/ Recent content in Applications on PrivSec.dev - Hugo -- gohugo.io - Sun, 02 Jan 2022 21:28:31 +0000 + Hugo -- gohugo.io F-Droid Security Analysis https://privsec.dev/apps/f-droid-security-analysis/ - Sun, 02 Jan 2022 21:28:31 +0000 + Mon, 01 Jan 0001 00:00:00 +0000 https://privsec.dev/apps/f-droid-security-analysis/ F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider. diff --git a/public/index.xml b/public/index.xml index 519db6c..180b218 100644 --- a/public/index.xml +++ b/public/index.xml @@ -4,31 +4,7 @@ PrivSec.dev https://privsec.dev/ Recent content on PrivSec.dev - Hugo -- gohugo.io - Wed, 30 Mar 2022 21:23:12 +0000 - - Docker and OCI Hardening - https://privsec.dev/os/docker-and-oci-hardening/ - Wed, 30 Mar 2022 21:23:12 +0000 - - https://privsec.dev/os/docker-and-oci-hardening/ - Containers aren&rsquo;t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem: -- Hey, your software doesn&rsquo;t work&hellip; -- Sorry, it works on my computer! Can&rsquo;t help you. -Whether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries. - - - - F-Droid Security Analysis - https://privsec.dev/apps/f-droid-security-analysis/ - Sun, 02 Jan 2022 21:28:31 +0000 - - https://privsec.dev/apps/f-droid-security-analysis/ - F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider. -Before we start, a few things to keep in mind: -The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else&rsquo;s work. - - + Hugo -- gohugo.io About Us https://privsec.dev/about/ @@ -41,6 +17,18 @@ Tommy System Administrator. Benevolent dictator for life @privsec.dev. Website: tommytran.io + + Docker and OCI Hardening + https://privsec.dev/os/docker-and-oci-hardening/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://privsec.dev/os/docker-and-oci-hardening/ + Containers aren&rsquo;t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem: +- Hey, your software doesn&rsquo;t work&hellip; +- Sorry, it works on my computer! Can&rsquo;t help you. +Whether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries. + + Donate https://privsec.dev/donate/ @@ -50,6 +38,17 @@ Website: tommytran.io The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted for free with Firebase. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project. + + F-Droid Security Analysis + https://privsec.dev/apps/f-droid-security-analysis/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://privsec.dev/apps/f-droid-security-analysis/ + F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider. +Before we start, a few things to keep in mind: +The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else&rsquo;s work. + + Linux Insecurities https://privsec.dev/os/linux-insecurities/ @@ -70,5 +69,15 @@ There is already a very indepth technical blog explaning the various security we Common protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification. + + Securing OpenSSH with FIDO2 + https://privsec.dev/os/securing-openssh-with-fido2/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://privsec.dev/os/securing-openssh-with-fido2/ + Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they&rsquo;re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They&rsquo;re also easier to manage while enabling a form of decentralized authentication (it&rsquo;s easy and painless to revoke them). So, what&rsquo;s the next step? And more exactly, why would one need something even better? +Why? The main problem with SSH keys is that they&rsquo;re not magic: they consist of a key pair, of which the private key is stored on your disk. + + diff --git a/public/os/docker-and-oci-hardening/index.html b/public/os/docker-and-oci-hardening/index.html index 07252e0..db0fabc 100644 --- a/public/os/docker-and-oci-hardening/index.html +++ b/public/os/docker-and-oci-hardening/index.html @@ -5,10 +5,10 @@ Whether we like them or not, containers are here to stay. Their expressiveness a
Home » Operating Systems

Docker and OCI Hardening

March 30, 2022 · 19 min · 3925 words · Wonderfall | Suggest Changes +Whether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries.">
Home » Operating Systems

Docker and OCI Hardening

19 min · 3925 words · Wonderfall | Suggest Changes  | Originally published at wonderfall.dev
Table of Contents

Containers aren’t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:

- Hey, your software doesn’t work…

- Sorry, it works on my computer! Can’t help you.

Whether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries. The developer can therefore provide a known-good environment where it is expected that their software “just works”. That is particularly useful for development to eliminate environment-related issues, and that is often used in production as well.

Containers are often perceived as a great tool for isolation, that is, they can provide an isolated workspace that won’t pollute your host OS - all that without the overhead of virtual machines. Security-wise: containers, as we know them on Linux, are glorified namespaces at their core. Containers usually share the same kernel with the host, and namespaces is the kernel feature for separating kernel resources across containers (IDs, networks, filesystems, IPC, etc.). Containers also leverage the features of cgroups to separate system resources (CPU, memory, etc.), and security features such as seccomp to restrict syscalls, or MACs (AppArmor, SELinux).

At first, it seems that containers may not provide the same isolation boundary as virtual machines. That’s fine, they were not designed to. But they can’t be simplified to a simple chroot either. We’ll see that a “container” can mean a lot of things, and their definition may vary a lot depending on the implementation: as such, containers are mostly defined by their semantics.

Docker is dead, long live Docker… and OCI!

When people think of containers, a large group of them may think of Docker. While Docker played a big role in the popularity of containers a few years ago, it didn’t introduce the technology: on Linux, LXC did (Linux Containers). In fact, Docker in its early days was a high-level wrapper for LXC which already combined the power of namespaces and cgroups. Docker then replaced LXC with libcontainer which does more or less the same, plus extra features.

Then, what happened? Open Container Initiative (OCI). That is the current standard that defines the container ecosystem. That means that whether you’re using Docker, Podman, or Kubernetes, you’re in fact running OCI-compliant tools. That is a good thing, as it saves a lot of interoperability headaches.

Docker is no longer the monolithic platform it once was. libcontainer was absorbed by runc, the reference OCI runtime. The high-level components of Docker split into different parts related to the upstream Moby project (Docker is the “assembled product” of the “Moby components”). When we refer to Docker, we refer in fact at this powerful high-level API that manages OCI containers. By design, Docker is a daemon that communicates with containerd, a lower-level layer, which in turn communicates with the OCI runtime. That also means that you could very well skip Docker altogether and use containerd or even runc directly.

Docker client <=> Docker daemon <=> containerd <=> containerd-shim <=> runc

Podman is an alternative to Docker developed by RedHat, that also intends to be a drop-in replacement for Docker. It doesn’t work with a daemon, and can work rootless by design (Docker has support for rootless too, but that is not without caveats). I would largely recommend Podman over Docker for someone who wants a simple tool to run containers and test code on their machine.

Kubernetes (also known as K8S) is the container platform made by Google. It is designed with scaling in mind, and is about running containers across a cluster whereas Docker focuses on packaging containers on a single node. Docker Swarm is the direct alternative to that, but it has never really took off due to the popularity of K8S.

For the rest of this article, we will use Docker as the reference for our examples, along with the Compose specification format. Most of these examples can be adapted to other platforms without issues.

The nightmare of dependencies

Containers are made from images, and images are typically built from a Dockerfile. Images can be built and distributed through OCI registries: Docker Hub, Google Container Registry, GitHub Container Registry, and so on. You can also set up your own private registry as well, but the reality is that people often pull images from these public registries.

Images, immutability and versioning

Images are what make containers, well, containers. Containers made from the same image should behave similary on different machines. Images can have tags, which are useful for software versioning. The usage of generic tags such as latest is often discouraged because it defeats the purpose of the expected behavior of the container. Tags are not necessarily immutable by design, and they shouldn’t be (more on that below). Digest, however, is the attribute of an immutable image, and is often generated with the SHA-256 algorithm.

docker.io/library/golang:1.17.1@sha256:232a180dbcbcfa7250917507f3827d88a9ae89bb1cdd8fe3ac4db7b764ebb25
          ^          ^       ^                                   ^ 
diff --git a/public/os/index.html b/public/os/index.html
index 69b1459..2b7dea7 100644
--- a/public/os/index.html
+++ b/public/os/index.html
@@ -2,8 +2,9 @@

Docker and OCI Hardening

Containers aren’t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem: - Hey, your software doesn’t work… - Sorry, it works on my computer! Can’t help you. -Whether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries....

March 30, 2022 · 19 min · 3925 words · Wonderfall

Linux Insecurities

There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality. -There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix’s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post....

1 min · 86 words · Tommy