diff --git a/config.yml b/config.yml index 38fadee..e07fcd7 100644 --- a/config.yml +++ b/config.yml @@ -20,13 +20,13 @@ params: ShowPostNavLinks: true ShowBreadCrumbs: true ShowWordCount: true - showtoc: true + ShowToc: true ShowRssButtonInSectionTermList: true ShowCodeCopyButtons: true assets: # disableHLJS: true # to disable highlight.js - # disableFingerprinting: true + disableFingerprinting: true favicon: "" favicon16x16: "" favicon32x32: "" @@ -78,7 +78,15 @@ params: distance: 1000 threshold: 0.4 minMatchCharLength: 0 - keys: ["title", "permalink", "summary", "content"] + keys: ["title", "summary"] + +#Enabling Search +outputs: + home: + - HTML + - RSS + - JSON # is necessary + menu: main: - identifier: Knowledge Base @@ -97,6 +105,10 @@ menu: name: Providers url: /providers/ weight: 40 + - identifier: Search + name: Search + url: /search/ + weight: 50 privacy: youtube: diff --git a/content/about.md b/content/about.md index abfa265..f158bf8 100644 --- a/content/about.md +++ b/content/about.md @@ -9,20 +9,24 @@ We focus on in-depth system configuration, security analysis, and software/hardw --- ### Tommy -Benevolent dictator for life @privsec.dev. System Administrator. +Benevolent dictator for life @PrivSec.dev. System Administrator. **Website**: [tommytran.io](https://tommytran.io)\ **Matrix**: [@tommy:arcticfoxes.net](https://matrix.to/#/@tommy:arcticfoxes.net)\ **Email**: [tommy@privsec.dev](mailto:tommy@privsec.dev) ### June -Privsec.dev Administrator. Security Researcher. GrapheneOS Developer. Excessively obsessed with Homestuck. +PrivSec.dev Administrator. Security Researcher. GrapheneOS Developer. Excessively obsessed with Homestuck. **Matrix**: [@june:grapheneos.org](https://matrix.to/#/@june:grapheneos.org)\ **Email**: [june@privsec.dev](mailto:june@privsec.dev) ### Randomhydrosol +<<<<<<< HEAD Privsec.dev Administrator. GrapheneOS Developer. Friendliest Indian tech support on the planet Earth. +======= +PrivSec.dev Administrator. GrapheneOS Developer. Friendliest Indian tech support on planet Earth. +>>>>>>> upstream/main **Matrix**: [@randomhydrosol:grapheneos.org](https://matrix.to/#/@randomhydrosol:grapheneos.org) diff --git a/content/knowledge/Multi-factor Authentication.md b/content/knowledge/Multi-factor Authentication.md index f66548a..b3b8b73 100644 --- a/content/knowledge/Multi-factor Authentication.md +++ b/content/knowledge/Multi-factor Authentication.md @@ -4,13 +4,13 @@ tags: ['knowledge base', 'security'] author: Tommy --- -**Multi-factor authentication** is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key. +**Multi-factor authentication** is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one-time passcode, a push notification, or plugging in and tapping a hardware security key. ## 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 receive your MFA verification. SMS, on the other hand, is problematic due to the lack of any kind of encryption, making it vulnerable to sniffing. [Sim swap](https://en.wikipedia.org/wiki/SIM_swap_scam) attacks, if carried out successfully, will allow an attacker to receive your one time passcode while locking you out of your own account. In certain cases, websites or services may also allow the user to reset their account login by calling them using the phone number used for MFA, which could be faked with a [spoofed CallerID](https://en.wikipedia.org/wiki/Caller_ID_spoofing). +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 receive your MFA verification. SMS, on the other hand, is problematic due to the lack of any kind of encryption, making it vulnerable to sniffing. [Sim swap](https://en.wikipedia.org/wiki/SIM_swap_scam) attacks, if carried out successfully, will allow an attacker to receive your one-time passcode while locking you out of your own account. In certain cases, websites or services may also allow the user to reset their account login by calling them using the phone number used for MFA, which could be faked with a [spoofed CallerID](https://en.wikipedia.org/wiki/Caller_ID_spoofing). Only use these protocols when it is the only option you have, and be very careful with SMS MFA as it could actually worsen your security. @@ -18,9 +18,9 @@ Only use these protocols when it is the only option you have, and be very carefu Push confirmation MFA is typically a notification being sent to an app on your phone asking you to confirm new account logins. This method is a lot better than SMS or email, since an attacker typically wouldn't be able to get these push notifications without having an already logged-in device. -Push comfirmation in most cases rely on a third party provider like [Duo](https://duo.com/). This means that trust is placed in a server that neither you nor your service provider control. A malicious push confirmation server could compromise your MFA or profile you based on which website and account you use with the service. +Push confirmation in most cases relies on a third party provider like [Duo](https://duo.com/). This means that trust is placed in a server that neither you nor your service provider control. A malicious push confirmation server could compromise your MFA or profile you based on which website and account you use with the service. -Even if the push notification application and server is provided by first party as is the case with Microsoft login and [Microsoft Authenticator](https://www.microsoft.com/en-us/security/mobile-authenticator-app), there is still a risk of you accidentally tapping on the confirmation button. +Even if the push notification application and server is provided by a first party as is the case with Microsoft login and [Microsoft Authenticator](https://www.microsoft.com/en-us/security/mobile-authenticator-app), there is still a risk of you accidentally tapping on the confirmation button. ### Time-based One-time Password (TOTP) @@ -32,7 +32,7 @@ If you have a [Yubikey](https://www.yubico.com/), you should store the "shared s Unlike [WebAuthn](#fido-fast-identity-online), TOTP offers no protection against [phishing](https://en.wikipedia.org/wiki/Phishing) or reuse attacks. If an adversary obtains a valid code from you, they may use it as many times as they like until it expires (generally 60 seconds + grace period). -Despite of its short comings, we consider TOTP better and safer than Push Confirmations. +Despite its short comings, we consider TOTP better and safer than Push Confirmations. ### Yubico OTP diff --git a/content/knowledge/Threat Modeling.md b/content/knowledge/Threat Modeling.md new file mode 100644 index 0000000..39d003d --- /dev/null +++ b/content/knowledge/Threat Modeling.md @@ -0,0 +1,92 @@ +--- +title: "Threat Modeling" +tags: ['knowledge base', 'privacy', 'security'] +author: Tommy +--- + +The first task a person should do when taking steps to protect their privacy and security is to make a threat model. + +## Defining a threat + +To make a threat model, we must first define a threat. A common mistake made by people who are just getting into the privacy space is to define the threat as "big-tech companies." There is a fundamental problem with this definition: + +Why are we not trusting "big-tech companies," but then shift our trust to "small-tech companies"? What happens if those "small-tech companies" turn out to be malicious? What happens when our favorite "small-tech company" becomes successful and grow exponentially? **The proper way to define the threat here is the "service provider," not "big-tech."** + +Generally, there are four primary threats a person would want to protect themselves from: + +- A service provider spying their users +- Cross site/service tracking and data sharing, a.k.a. "mass surveillance" +- An app developer spying on users through their malicious software +- A hacker trying to get into the users' computers + +A typical person would have several of these threats in their threat model. Some of these threats may weigh more than others. For example, a software developer would have a hacker stealing their source code, signing keys and secrets as their primary threat, but beyond that they would also want privacy from the websites they visit and so on. Likewise, an average Joe may have their primary threat as mass surveillance and service providers, but beyond that they also need to have decent security to prevent a hacker from stealing their data. + +For whistleblowers, the threat model is much more extreme. Beyond what is mentioned above, they also need anonymity. Beyond just hiding what they do, what data they have, not getting hacked by hackers or governments, they also have to hide who they are. + +## Privacy from service providers + +In most setups, our "private" messages, emails, social interactions are typically stored on a server somewhere. The obvious problem with this is that the service provider (or a hacker who has compromised the server) can look into your "private" conversations whenever and however they want, without you ever knowing. This applies to many common services like SMS messaging, Telegram, Discord, and so on. + +With end-to-end encryption, you can alleviate this issue by encrypting communications between you and your desired recipients before they are even sent to the server. The confidentiality of your messages is guaranteed, so long as the service provider does not have access to the private keys of either party. + +In practice, the effectiveness of different end-to-end encryption implementations varies. Applications such as Signal run natively on your device, and every copy of the application is the same across different installations. If the service provider were to backdoor their application in an attempt to steal your private keys, that could later be detected using reverse engineering. + +On the other hand, web-based end-to-end encryption implementations such as Proton Mail's webmail or Bitwarden's web vault rely on the server dynamically serving JavaScript code to the browser to handle cryptographic operations. A malicious server could target a specific user and send them malicious JavaScript code to steal their encryption key, and it would be extremely hard for the user to ever notice such a thing. Even if the user does notice the attempt to steal their key, it would be incredibly hard to prove that it is the provider trying to do so, because the server can choose to serve different web clients to different users. + +Therefore, when relying on end-to-end encryption, you should choose to use native applications over web clients whenever possible. + +Even with end-to-end encryption, service providers can still profile you based on **metadata**, which is typically not protected. While the service provider could not read your messages to see what you're saying, they can still observe things like who you're talking to, how often you message them, and what times you're typically active. Protection of metadata is fairly uncommon, and you should pay close attention to the technical documentation of the software you are using to see if there is any metadata minimization or protection at all, if that is a concern for you. + +## Protection from cross site/service tracking +You can be tracked across websites and services using some form of identifiers. These are typically: + +- Your IP address +- Browser cookies +- Your browser fingerprint +- Data you submit to websites +- Payment method correlation + +Your goals should be to segregate your online identities from each other, to blend in with other people, and simply to avoid giving out identifying information to anyone as much as possible. + +Instead of relying on privacy policies (which are promises that could be violated), try to obfuscate your information in such a way that it is very difficult for different providers to correlate data with each other and build a profile on you. This could come in the form of using encryption tools like Cryptomator prior to uploading your data to cloud services, using prepaid cards or cryptocurrency to protect your credit/debit card information, using a VPN to hide your IP address from websites and services on the internet, etc. The privacy policy should only be relied upon as a last resort, when you have exhausted all of your option for true privacy and need to put complete trust in your service provider. + +Bear in mind that companies can hide their ownership or share your information with data brokers, even if they are not in the advertising business. Thus, it makes little sense to solely focus on the "ad-tech" industry as a threat in your threat model. Rather, it makes a lot more sense to protect yourself from service providers as a whole, and any kind of corporate surveillance threat that most people are concerned about will be thwarted along with the rest. + +## Limiting Public Information + +The best way to ensure your data is private is to simply not put it out there in the first place. Deleting information you find about yourself online is one of the best first steps you can take to regain your privacy. + +On sites where you do share information, checking the privacy settings of your account to limit how widely that data is spread is very important. For example, if your accounts have a "private mode," enable it to make sure your account isn't being indexed by search engines and can't be viewed by people you don't vet beforehand. + +If you have already submitted your real information to a number of sites which shouldn't have it, consider employing disinformation tactics such as submitting fictitious information related to the same online identity to make your real information indistinguishable from the false information. + +## Protection from malware and hackers + +You need security to obtain any semblance of privacy: **Using tools which appear private is futile if they could easily be exploited by attackers to release your data later.** + +When it comes to application security, we generally do not (and sometimes cannot) know if the software that we use is malicious, or might one day become malicious. Even with the most trustworthy developers, there is generally no guarantee that their software does not have a serious vulnerability that could later be exploited. + +To minimize the potential damage that a malicious piece of software can do, you should employ security by compartmentalization. This could come in the form of using different computers for different jobs, using virtual machines to separate different groups of related applications, or using a secure operating system with a strong focus on application sandboxing and mandatory access control. + +Mobile operating systems are generally safer than desktop operating systems when it comes to application sandboxing. Apps cannot obtain root access and only have access to system resources which you grant them. + +Desktop operating systems generally lag behind on proper sandboxing. ChromeOS has similar sandboxing properties to Android, and macOS has full system permission control and opt-in (for developers) sandboxing for applications, however these operating systems do transmit identifying information to their respective OEMs. Linux tends to not submit information to system vendors, but it has poor protection against exploits and malicious apps. This can be mitigated somewhat with specialized distributions which make heavy use of virtual machines or containers, such as Qubes OS. + +Web browsers, email clients, and office applications all typically run untrusted code sent to you from third-parties. Running multiple virtual machines to separate applications like these from your host system as well as each other is one technique you can use to avoid an exploit in these applications from compromising the rest of your system. Technologies like Qubes OS or Microsoft Defender Application Guard on Windows provide convenient methods to do this seamlessly, for example. + +If you are concerned about physical attacks you should use an operating system with a secure verified boot implementation, such as Android, iOS, ChromeOS, or macOS. You should also make sure that your drive is encrypted, and that the operating system uses a TPM or Secure [Enclave](https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/1/web/1) or [Secure Element](https://developers.google.com/android/security/android-ready-se) for rate limiting attempts to enter the encryption passphrase. You should avoid sharing your computer with people you don't trust, because most desktop operating systems do not encrypt data separately per-user. + +## Bad Practices +As a beginner, you may often fall into some bad practices while making a threat model. These include: + +- Solely focusing on advertising networks instead of service providers as a whole +- Heavy reliance on privacy policies +- Blindly shifting trust from one service provider to another +- Heavy reliance on badness enumeration for privacy instead of systematically solving the problem +- Blindly trusting open-source software + +As discussed, focusing solely on advertising networks and relying solely on privacy policies does not make up a sensible threat model. When switching away from a service provider, try to determine what the root problem is and see if your new provider has any technical solution to the problem. For example, you may not like Google Drive as it means giving Google access to all of your data. The underlying problem here is the lack of end to end encryption, which you can solve by using an encryption tool like Cryptomator or by switching to a provider who provides it out of the box like Proton Drive. Blindly switching from Google Drive to a provider who does not provide end to end encryption like the Murena Cloud does not make sense. + +Badness enumeration cannot provide any privacy guarantee and should not be relied upon against real threat actors. While things like ad blockers may help block the low hanging fruits that is common tracking domains, they are trivially bypassed by just using a new domain that is not on common blacklists, or proxying third-party tracking code on the first part domain. Likewise, antivirus software may help you quickly detect common malware with known signatures, but they can never fully protect you from said threat. + +Another thing to keep in mind is that open-source software is not automatically private or secure. Malicious code can be sneaked into the package by the developer of the project, contributors, library developers or the person who compile the code. Beyond that, sometimes, a piece of open-source software may have worse security properties than its proprietary counterpart. An example of this would be traditional Linux desktops lacking verified boot, system integrity protection, or a full system access control for apps when compared to macOS. When doing threat modeling, it is vital that you evaluate the privacy and security properties of each piece of software being used, rather than just blindly trusting it because it is open-source. diff --git a/content/os/Choosing Your Android-Based Operating System.md b/content/os/Choosing Your Android-Based Operating System.md new file mode 100644 index 0000000..3415cde --- /dev/null +++ b/content/os/Choosing Your Android-Based Operating System.md @@ -0,0 +1,109 @@ +--- +title: "Choosing Your Android-Based Operating System" +tags: ['operating systems', 'android', 'privacy', 'security'] +author: Tommy +--- + +Android is a secure operating system that has strong [app sandboxing](https://source.android.com/security/app-sandbox), [Verified Boot](https://source.android.com/security/verifiedboot) (AVB), and a robust [permission](permission) control system. + +When you buy an Android phone, the device's default operating system often comes with invasive integration with apps and services that are not part of the [Android Open-Source Project](https://source.android.com/). An example of such is Google Play Services, which has irrevocable privileges to access your files, contacts storage, call logs, SMS messages, location, camera, microphone, hardware identifiers, and so on. These apps and services increase the attack surface of your device and are the source of various privacy concerns with Android. + +This problem could be solved by using a custom Android-based operating system that does not come with such invasive integration. Unfortunately, many custom Android-based operating systems often violate the Android security model by not supporting critical security features such as AVB, rollback protection, firmware updates, and so on. Some of them also ship [`userdebug`](https://source.android.com/setup/build/building#choose-a-target) builds which expose root over [ADB](https://developer.android.com/studio/command-line/adb) and require [more permissive](https://github.com/LineageOS/android_system_sepolicy/search?q=userdebug&type=code) SELinux policies to accommodate debugging features, resulting in a further increased attack surface and weakened security model. + +When choosing a custom Android-based operating system, you should make sure that it upholds the Android security model. Ideally, the custom operating system should have substantial privacy and security improvements to justify adding yet another party to trust. + +## Baseline Security + +### Verified Boot + +![Verified Boot](/verified-boot.png) + +[Verified Boot](https://source.android.com/security/verifiedboot) is an important part of the Android security model. It provides protection against [evil maid](https://en.wikipedia.org/wiki/Evil_maid_attack) attacks, malware persistence, and ensures security updates cannot be downgraded with [rollback protection](https://source.android.com/security/verifiedboot/verified-boot#rollback-protection). + +Android 10 and above has moved away from full-disk encryption to more flexible [file-based encryption](https://source.android.com/security/encryption/file-based). Your data is encrypted using unique encryption keys, and the operating system files are left unencrypted. + +Verified Boot ensures the integrity of the operating system files, thereby preventing an adversary with physical access from tampering or installing malware on the device. In the unlikely case that malware is able to exploit other parts of the system and gain higher privileged access, Verified Boot will prevent and revert changes to the system partition upon rebooting the device. + +Unfortunately, OEMs are only obliged to support Verified Boot on their stock Android distribution. Only a few OEMs such as Google support custom AVB key enrollment on their devices. Additionally, some AOSP derivatives such as LineageOS or /e/ OS do not support Verified Boot even on hardware with Verified Boot support for third-party operating systems. These AOSP derivatives should be avoided at all cost. + +### Firmware Updates + +Firmware updates are critical for maintaining security and without them your device cannot be secure. OEMs have support agreements with their partners to provide the closed-source components for a limited support period. These are detailed in the monthly [Android Security Bulletins](https://source.android.com/security/bulletin). + +On a custom Android distribution, it is the responsibility of the operating system vendor to extract the firmware from the stock operating system, test it against their Android builds, then ship them to the user. + +Unfortunately, many custom Android distributions, including extremely popular ones like LineageOS and /e/ OS do not ship firmware updates for most of their supported device. Instead, they expect the user to keep track of stock OS updates, extract and flash the firmware themselves. Beyond the lack of testing, this is extremely burdensome and not feasible for most end users and is yet another reason to not use these distributions. + +### Patch Levels + +As the [Android Security Bulletins](https://source.android.com/security/bulletin) is updated every month, Android-Based operating systems are expected to apply all security fixes before the next bulletin update comes out. Beside extracting the firmware, testing it and shipping it to the end user as described [above](#firmware-updates), the AOSP based system also need to be updated. + +This is a particularly challenging thing to do, especially around the time of a new major Android release since there are a lot of changes. Sometimes, newer firmware versions require newer major versions of AOSP, and if the developer takes too long to update their base operating system to the next major AOSP version, they cannot ship firmware updates either, leaving users vulnerable. + +This has happened to CalyxOS during the Android 11 to Android 12 transition. It took them [4 months](https://github.com/privacyguides/privacyguides.org/pull/578#issue-1112002737) to update to Android 12; and during those 4 months, they could not ship any firmware updates at all, leaving the user vulnerable during that time period. + +It would be much better if you just stick to the stock operating system (which got updated to Android 12 shortly after the AOSP 12 release) instead of using a custom operating system which could not keep up with updates as described. + +### Chromium Webview Updates + +Android comes with a system [webview](https://developer.android.com/reference/android/webkit/WebView), a component that many apps rely on to use as part of their activity layout. It effectively behaves like a minimal browser, opening random websites with arbitrary code the internet. Thus, it is very important that this component is consistently kept up to dater. + +Some Android-based operating systems, including ones like CalyxOS, often fall behind on security updates for this component. Particularly, this has gotten so bad that they actually fell behind for [3 months](https://github.com/privacyguides/privacyguides.org/pull/548#issuecomment-1018245074) back in January 2022 and [2 months](https://github.com/privacyguides/privacyguides.org/pull/1378) in June 2022. It is a good indication that these operating systems cannot keep up with security updates and should not be used. + +### User Builds + +As mentioned [above](/os/choosing-your-android-based-operating-system/), `userdebug` builds expose root over ADB and require more permissive SELinux policies to accommodate debugging features. `userdebug` builds violate the Android security model and are really only meant for developers to test out their android builds during development. + +End users should be using the production `user` builds, and any distributions that fail to deliver them like LineageOS or /e/ OS should be avoided. + +### SELinux in Enforcing Mode + +[SELinux](https://source.android.com/security/selinux) is a critical part of the Android security model, having the Linux kernel enforcing confinement for all processes, including system processes running as root. + +In order for a system to be secure, it must have SELinux in Enforcing mode, accompanied by fine-grained SELinux policies. + +Unfortunately, many custom Android-based operating system builds (especially unofficial LineageOS builds) disables SELinux or set it into Permissive mode. You can check whether SELinux is in enforcing mode or not by executing `getenforce` in the ADB shell (the expected output is `Enforcing`). You should avoid any Android-based operating system builds that do not have SELinux in enforcing mode at all cost. + +![ADB SELinux](/adb-selinux.png) + +## Good Android-Based Operating Systems + +Currently, I am only aware of two Android-based operating systems that should be used over the stock operating systems: + +### GrapheneOS +![GrapheneOS Phone & Cat](/grapheneos-phone-cat.jpg) + +[GrapheneOS](https://grapheneos.org) is the **only** custom Android-based operating system you should buy a new phone for. It provides additional [security hardening](https://en.wikipedia.org/wiki/Hardening_(computing)) and privacy improvements over the stock operating system from Google. It has a [hardened memory allocator](https://github.com/GrapheneOS/hardened_malloc), network and sensor permissions, and various other [security feature](https://grapheneos.org/features). GrapheneOS also comes with full firmware updates and signed builds, so verified boot is fully supported. + +For usability purposes, GrapheneOS supports [Sandboxed Google Play](https://grapheneos.org/usage#sandboxed-google-play), which runs Google Play Services fully sandboxed like any other regular app. This means you can take advantage of most Google Play Services, such as [push notifications](https://firebase.google.com/docs/cloud-messaging/), while giving you full control over their permissions and access, and while containing them to a specific work profile or user profile of your choice. Most interestingly, the [In-app Billing API](https://android-doc.github.io/google/play/billing/api.html), [Google Play Games](https://play.google.com/googleplaygames), [Play Asset Delivery](https://developer.android.com/guide/playcore/asset-delivery), [FIDO2](/knowledge/multi-factor-authentication/#fido2-fast-identity-online) all work exceptionally well. Most [Advanced Protection Program](https://landing.google.com/advancedprotection/) features, except for [Play Protect](https://support.google.com/googleplay/answer/2812853?hl=en) and restricted app installation, also work. + +Because GrapheneOS does not grant any Google Apps and Services apart from the opt-in eSIM action app privileged access to the system, Play Protect cannot disable or uninstall known malicious applications when it detects them. As for restricted app installation, this feature is not that useful on stock operating system anyways, since it is bypassable with `adb push`. + +Recently, GrapheneOS has also added the [Storage Scopes](https://grapheneos.org/usage#storage-access) feature, allowing you to limit what legacy apps which still use the old storage API can access. With this new feature, you no longer have to grant certain apps access to all of your media or files to use them anymore. + +![VLC Storage Scopes](/vlc-storage-scopes.png) + +Currently, Google Pixel phones are the only devices that meet GrapheneOS's [hardware security requirements](https://grapheneos.org/faq#device-support). + +### DivestOS + +<<<<<<< HEAD +[DivestOS](https://divestos.org/) is a great aftermarket operating system for devices that have gone end of life or near end of life. Note that this is a harm reduction project, run by one developer on a best effort basis, and you should not buy a new device just to run DivestOS. +======= +DivestOS is a great aftermarket operating system for devices that have gone end-of-life or near end-of-life. Note that this is a harm reduction project, run by one developer on a best effort basis, and you should not buy a new device just to run DivestOS. +>>>>>>> 7dd45472f23bcd00539a1afe4a79f9b1fdafcff6 + +Being a soft-fork of [LineageOS](https://lineageos.org/), DivestOS inherits many [supported devices](https://divestos.org/index.php?page=devices&base=LineageOS) from LineageOS. It has signed builds, making it possible to have [verified boot](https://source.android.com/security/verifiedboot) on some non-Pixel devices. + +It comes with substantial hardening over AOSP. DivestOS has automated kernel vulnerability ([CVE](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures)) [patching](https://gitlab.com/divested-mobile/cve_checker), fewer proprietary blobs, a custom [hosts](https://divested.dev/index.php?page=dnsbl) file, and various security features ported from GrapheneOS. A non-exhaustive list of this includes: + +- A hardened webview. [Mulch](https://gitlab.com/divested-mobile/mulch) comes with *some* patches from GrapheneOS's Vanadium browser and the [Bromite](https://github.com/bromite/bromite) project. It gets updated fairly quickly and do not fall behind nearly as much as Bromite. +- Kernel patches from GrapheneOS and enables all available kernel security features via [defconfig hardening](https://github.com/Divested-Mobile/DivestOS-Build/blob/master/Scripts/Common/Functions.sh#L758). All kernels newer than version 3.4 include full page [sanitization](https://lwn.net/Articles/334747/) and all ~22 Clang-compiled kernels have [`-ftrivial-auto-var-init=zero`](https://reviews.llvm.org/D54604?id=174471) enabled. +- GrapheneOS's [`INTERNET`](https://developer.android.com/training/basics/network-ops/connecting) and SENSORS permission toggle. +- [Hardened memory allocator](https://github.com/GrapheneOS/hardened_malloc) +- [Secure Exec-Spawning](android/grapheneos-vs-calyxos.md#additional-hardening) +- Partial [bionic](https://en.wikipedia.org/wiki/Bionic_(software)) hardening patchsets from GrapheneOS +- GrapheneOS's per-network full [MAC randomization](https://en.wikipedia.org/wiki/MAC_address#Randomization) option on version 17.1 and higher +- Automatic reboot/Wi-Fi/Bluetooth [timeout options](https://grapheneos.org/features) + +With that being said, DivestOS is not without its faults. The developer does not have all of the devices he is building for, and for a lot of them he simply publishes the builds blind without actually testing them. Firmware update support [varies](https://gitlab.com/divested-mobile/firmware-empty/-/blob/master/STATUS) across devices. DivestOS also takes a very long time to update to a new major Android, and actually took longer than CalyxOS did as mentioned [above](#firmware-updates). diff --git a/content/os/Choosing Your Desktop Linux Distribution.md b/content/os/Choosing Your Desktop Linux Distribution.md index 6f6f779..292c7a4 100644 --- a/content/os/Choosing Your Desktop Linux Distribution.md +++ b/content/os/Choosing Your Desktop Linux Distribution.md @@ -1,6 +1,6 @@ --- title: "Choosing Your Desktop Linux Distribution" -tags: ['operating system', 'security', 'linux'] +tags: ['operating systems', 'linux', 'security'] author: Tommy --- @@ -75,7 +75,7 @@ Here is a quick non authoritative list of distributions that are generally bette ![Fedora](/fedora-screenshot.png) -Fedora Workstation is a great general purpose Linux distribution, especially for those who are new to Linux. It is a semi-rolling release distribution. While some packages like GNOME are frozen until the next Fedora release, most packages (including the kernel) are updated frequently throughout the lifespan of the release. Each Fedora release is supported for one year, with a new version released every 6 months. +[Fedora Workstation](https://getfedora.org/en/workstation/) is a great general purpose Linux distribution, especially for those who are new to Linux. It is a semi-rolling release distribution. While some packages like GNOME are frozen until the next Fedora release, most packages (including the kernel) are updated frequently throughout the lifespan of the release. Each Fedora release is supported for one year, with a new version released every 6 months. WIth that, Fedora generally adopts newer technologies before other distributions e.g., [Wayland](https://wayland.freedesktop.org/), [PipeWire](https://pipewire.org/), and soon, [FS-Verity](https://fedoraproject.org/wiki/Changes/FsVerityRPM). These new technologies often come with improvements in security, privacy, and usability in general. @@ -83,7 +83,7 @@ While lacking transactional or atomic updates, Fedora's package manager, `dnf`, ### Fedora Silverblue & Kinoite -Fedora Silverblue and Fedora Kinoite are immutable variants of Fedora with a strong focus on container workflows. Silverblue comes with the [GNOME](https://www.gnome.org/) desktop environment while Kinoite comes with [KDE](https://kde.org/). Silverblue and Kinoite follow the same release schedule as Fedora Workstation, benefiting from the same fast updates and staying very close to upstream. +[Fedora Silverblue](https://silverblue.fedoraproject.org/) and [Fedora Kinoite](https://kinoite.fedoraproject.org/) are immutable variants of Fedora with a strong focus on container workflows. Silverblue comes with the [GNOME](https://www.gnome.org/) desktop environment while Kinoite comes with [KDE](https://kde.org/). Silverblue and Kinoite follow the same release schedule as Fedora Workstation, benefiting from the same fast updates and staying very close to upstream. You can refer to the video by [Adam Šamalík](https://twitter.com/adsamalik) linked [above](#traditional-and-atomic-updates) on how these distributions work. @@ -91,13 +91,13 @@ You can refer to the video by [Adam Šamalík](https://twitter.com/adsamalik) li Fedora Workstation and Silverblue's European counterpart. These are rolling release, fast updating distributions with [transactional update](https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/) using [Btrfs](https://en.wikipedia.org/wiki/Btrfs) and [Snapper](https://en.opensuse.org/openSUSE:Snapper_Tutorial). -MicroOS has a much smaller base system than Tumbleweed and mounts the running BTRFS subvomumes as read-only (hence its name and why it is considered an immutable distribution). Currently, it is still in Beta so bugs are to be expected. Nevertheless, it is an awesome project. +[MicroOS](https://microos.opensuse.org/) has a much smaller base system than [Tumbleweed](https://get.opensuse.org/tumbleweed) and mounts the running BTRFS subvomumes as read-only (hence its name and why it is considered an immutable distribution). Currently, it is still in Beta so bugs are to be expected. Nevertheless, it is an awesome project. {{< youtube id="jcl_4Vh6qP4">}} ### Whonix -Whonix is a distribution focused on anonimity based on [Kicksecure](https://www.whonix.org/wiki/Kicksecure). It is meant to run as two virtual machines: a “Workstation” and a Tor “Gateway.” All communications from the Workstation must go through the Tor gateway. This means that even if the Workstation is compromised by malware of some kind, the true IP address remains hidden. +[Whonix](https://www.whonix.org/) is a distribution focused on anonimity based on [Kicksecure](https://www.whonix.org/wiki/Kicksecure). It is meant to run as two virtual machines: a “Workstation” and a Tor “Gateway.” All communications from the Workstation must go through the Tor gateway. This means that even if the Workstation is compromised by malware of some kind, the true IP address remains hidden. Some of its features include Tor Stream Isolation, [keystroke anonymization](https://www.whonix.org/wiki/Keystroke_Deanonymization#Kloak), [encrypted swap](https://github.com/Whonix/swap-file-creator), and a hardened memory allocator. @@ -107,6 +107,6 @@ Although Whonix is best used [in conjunction with Qubes](https://www.whonix.org/ ### Tails -Tails is a live operating system based on Debian focusing on anonimity and amnesia. +[Tails](https://tails.boum.org/) is a live operating system based on Debian focusing on anonimity and amnesia. While it is great for counter forensics as nothing is written to the disk; it is not a hardened distribution like Whonix. It lacks many anonymity and security features that Whonix has and gets updated much less often (only once every six weeks). A Tails system that is compromised by malware may potentially bypass the transparent proxy allowing for the user to be deanonymized. \ No newline at end of file diff --git a/content/os/Linux Insecurities.md b/content/os/Linux Insecurities.md index 59f8cfa..a3d6ef5 100644 --- a/content/os/Linux Insecurities.md +++ b/content/os/Linux Insecurities.md @@ -12,9 +12,9 @@ There is already a very in-depth technical blog explaining the various security ## Why is Linux used on servers if it is so insecure? -On servers, while most of the problems referenced in the article still exists, they are somewhat less problematic. +On servers, while most of the problems referenced in the article still exist, they are somewhat less problematic. -On Desktop Linux, GUI applications run under your user, and thus have access to all of your files in `/home`. This is in contrast to how system daemons typically run on servers, where they have their own group and user. For example, NGINX will run under `nginx:nginx` on Red Hat distributions, or `www-data:www-data` on Debian based ones. Discreationary Access Control does help with filesystem access control for server processes, but is useless for desktop applications. +On Desktop Linux, GUI applications run under your user, and thus have access to all of your files in `/home`. This is in contrast to how system daemons typically run on servers, where they have their own group and user. For example, NGINX will run under `nginx:nginx` on Red Hat distributions, or `www-data:www-data` on Debian based ones. Discretionary Access Control does help with filesystem access control for server processes, but is useless for desktop applications. Another thing to keep in mind is that Mandatory Access Control is also somewhat effective on servers, as commonly run system daemons are confined. In contrast, on desktop, there is virtually no AppArmor profile to confine even regularly used apps like Chrome or Firefox, let alone less common ones. On SELinux systems, these apps run in the UNCONFINED SELinux domain. @@ -22,7 +22,7 @@ Linux servers are lighter than Desktop Linux systems by order of magnitude, with ## Linux Hardening Myths -There is a common claim in response to Madaidan that Linux is only insecure by default, and that an experience user can make it the most secure operating system out there, surpassing the likes of macOS or ChromeOS. Unfortunately, this is wishful thinking. There is no amount of hardening that one can reasonably apply as a user to fix up the inherent issues with Linux. +There is a common claim in response to Madaidan that Linux is only insecure by default, and that an experienced user can make it the most secure operating system out there, surpassing the likes of macOS or ChromeOS. Unfortunately, this is wishful thinking. There is no amount of hardening that one can reasonably apply as a user to fix up the inherent issues with Linux. ### Lack of verified boot @@ -34,12 +34,12 @@ On Linux, there is no such clear distinction between the system and user install Operating systems like Android and ChromeOS have full system mandatory access control, every process from the init process is strictly confined. Regardless of which application you install or how you install them, they have to play by the rules of an untrusted SELinux domain and are only able to utilize unprivileged APIs. -Even on macOS, where the application sandbox is opt-in for developers, there is still a system wide permission control for unprivileged application. Apps run by the user do not have unrestricted access their microphone, webcam, keystrokes, sensitive documents, and so on. +Even on macOS, where the application sandbox is opt-in for developers, there is still a system wide permission control for unprivileged application. Apps run by the user do not have unrestricted access to their microphone, webcam, keystrokes, sensitive documents, and so on. On Linux, it is quite the opposite. Out of the box, most systems only have a few system daemons confined. Some Linux distributions don't even have a Mandatory Access Control system at all. Applications are designed in an environment where they expect to be able to do whatever they want, and the app sandboxes/mandatory access control system are merely an afterthought trying to restrict an app to only access what it expects to be accessible. -This is reflected in the under utilization of the [Portals API](https://docs.flatpak.org/en/latest/portal-api-reference.html) as an example. Portals is designed to be an API where apps have to prompt the user to access their files (through the File Manager) or their microphone and camera. Unfortunately, the vast majority of apps are not designed with this in mind, and expect direct access to the filesystem, pulseaudio socket or the entire /dev. As a result, Flatpak maintainers often opt to have extremely laxed permissions to the point where they have to grant `filesystem=home`, `filesystem=host`, `socket=pulseaudio` or `devices=all`, otherwise apps will break and give users a bad experience. +This is reflected in the under utilization of the [Portals API](https://docs.flatpak.org/en/latest/portal-api-reference.html) as an example. Portals is designed to be an API where apps have to prompt the user to access their files (through the File Manager) or their microphone and camera. Unfortunately, the vast majority of apps are not designed with this in mind, and expect direct access to the filesystem, pulseaudio socket or the entire /dev. As a result, Flatpak maintainers often opt to have extremely lax permissions to the point where they have to grant `filesystem=home`, `filesystem=host`, `socket=pulseaudio` or `devices=all`, otherwise apps will break and give users a bad experience. -To make matters worse, some system daemons are not designed with permission control in mind at all. For example, PulseAudio does not have any concept of audio in or out permission. Thus, the user is often left with only the choice of granting an app access to the socket or not. If they want to block microphone access, they have to block access to the socket, and thus break audio playback in the process. If they do want an auudio playback, then they have to allow access to the PulseAudio socket, which in turns give an app unrestricted access to record them at any moment. +To make matters worse, some system daemons are not designed with permission control in mind at all. For example, PulseAudio does not have any concept of audio in or out permission. Thus, the user is often left with only the choice of granting an app access to the socket or not. If they want to block microphone access, they have to block access to the socket, and thus break audio playback in the process. If they do want an audio playback, then they have to allow access to the PulseAudio socket, which in turns give an app unrestricted access to record them at any moment. -The only way to systematically fix this problem is to design a whole new system from stratch with a permission model like that of Android in mind. And even when that happens, it will take substantial work to get developers to develop their apps for said system. \ No newline at end of file +The only way to systematically fix this problem is to design a whole new system from scratch with a permission model like that of Android in mind. And even when that happens, it will take substantial work to get developers to develop their apps for said system. diff --git a/content/search.md b/content/search.md new file mode 100644 index 0000000..3d2fadc --- /dev/null +++ b/content/search.md @@ -0,0 +1,8 @@ +--- +title: "Search" # in any language you want +layout: "search" # is necessary +# url: "/archive" +# description: "Description for Search" +summary: "search" +placeholder: "Enter your search query" +--- \ No newline at end of file diff --git a/static/adb-selinux.png b/static/adb-selinux.png new file mode 100644 index 0000000..937667c Binary files /dev/null and b/static/adb-selinux.png differ diff --git a/static/grapheneos-phone-cat.jpg b/static/grapheneos-phone-cat.jpg new file mode 100644 index 0000000..23e9b4c Binary files /dev/null and b/static/grapheneos-phone-cat.jpg differ diff --git a/static/verified-boot.png b/static/verified-boot.png new file mode 100644 index 0000000..9500e82 Binary files /dev/null and b/static/verified-boot.png differ diff --git a/static/vlc-storage-scopes.png b/static/vlc-storage-scopes.png new file mode 100644 index 0000000..8c0f1d5 Binary files /dev/null and b/static/vlc-storage-scopes.png differ