User:Pursuable1652: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| (8 intermediate revisions by the same user not shown) | |||
| Line 15: | Line 15: | ||
Desktop may have a more harder way of controlling the security of software, since you need the support of an app ecosystem already working on a predefined-security focused platform, so not all apps are just running without a sandbox/vm (ideally without a VM (run all in sandbox) or maybe just one, because using virtual machines has a performance loss). | Desktop may have a more harder way of controlling the security of software, since you need the support of an app ecosystem already working on a predefined-security focused platform, so not all apps are just running without a sandbox/vm (ideally without a VM (run all in sandbox) or maybe just one, because using virtual machines has a performance loss). | ||
To be honest, I recommend using Android/AOSP and ChromeOS/ChromiumOS for a secure OS based on Linux kernel, since they already have a huge app ecosystem built with Java and Kotlin, based on an SELinux'ed platform with Verified Boot enabled by default, and root disallowed by default. | |||
Apparently Google is discontinuing ChromeOS/ChromiumOS, so let's see what goes on with Android. | |||
---- | ---- | ||
| Line 46: | Line 50: | ||
Get rid of debugging tools. | Get rid of debugging tools. | ||
Use <code>doas</code> and <code>doasedit</code> if root is needed. (I believe <code>doasedit</code> is in the testing repo.) | |||
There is the obvious, which is DISABLE internet access to specific sandboxed/virtualized applications, or disable internet as a whole for a device if practical. (Basically firewalling) | |||
File encryption can be used in tandem with FDE, for granular encryption. | |||
Same could be said for read-only integrity for files/directories. | |||
---- | ---- | ||
| Line 52: | Line 65: | ||
Security should be done by default, if not, while you configure your operating system for security, you are already compromised from the start. And more secure users is better than less, for example as you communicate with other secure users you are protected as well, protecting your communications with others. | Security should be done by default, if not, while you configure your operating system for security, you are already compromised from the start. And more secure users is better than less, for example as you communicate with other secure users you are protected as well, protecting your communications with others. | ||
Follow DM-Verity wiki for an attempt at verified boot on Alpine Linux. | Follow [https://wiki.alpinelinux.org/wiki/DM-verity DM-Verity] wiki for an attempt at full verified/trusted boot on Alpine Linux. | ||
---- | ---- | ||
At this point, it would be it's own Linux distro | At this point, it would be it's own Linux distro | ||
Latest revision as of 02:04, 18 December 2024
Hello, I'm Pursuable1652 and I helped make these wiki pages:
- https://wiki.alpinelinux.org/wiki/Hardened_linux
- https://wiki.alpinelinux.org/wiki/DM-verity
- https://wiki.alpinelinux.org/wiki/Silent_boot
- https://wiki.alpinelinux.org/wiki/Hardened_malloc
My main goal is to secure Linux more, and better (and as a side-effect, very different) than traditional Linux distros. My guide is more suited to a server use-case, rather than desktop.
The guides still apply to both server and desktop, but desktop has a bigger attack surface usually, because an app ecosystem must be incorporated with security as its designed (compared to server which could just be dockerized + gvisored + apparmored/selinuxed or virtualized).
Flatpak on desktop is somewhat flawed because it's allow-permission first, rather than deny-permission first.
It might be thought of as, you compile the software, the software is open-source, so it must be secure, right? (That is not true, because software, especially software with bigger LOC (lines of code), will be more complex, thus may have more bugs that are hard to detect from the human-eye, and these bugs may do any rogue things to your system.)
Desktop may have a more harder way of controlling the security of software, since you need the support of an app ecosystem already working on a predefined-security focused platform, so not all apps are just running without a sandbox/vm (ideally without a VM (run all in sandbox) or maybe just one, because using virtual machines has a performance loss).
To be honest, I recommend using Android/AOSP and ChromeOS/ChromiumOS for a secure OS based on Linux kernel, since they already have a huge app ecosystem built with Java and Kotlin, based on an SELinux'ed platform with Verified Boot enabled by default, and root disallowed by default.
Apparently Google is discontinuing ChromeOS/ChromiumOS, so let's see what goes on with Android.
Some wikis I did not write, but may help with security of Alpine Linux (or just miscellaneous):
- https://wiki.alpinelinux.org/wiki/AppArmor (or possibly SELinux if your kernel supports it, default linux-lts doesn't)
- https://wiki.alpinelinux.org/wiki/Docker (if you use docker, also use GVisor for full sandboxing)
- https://wiki.alpinelinux.org/wiki/Securing_Alpine_Linux
- https://wiki.alpinelinux.org/wiki/Sysctl.conf#Security (can also use kernel-hardening-checker for suggestions on sysctl and boot parameter secure options)
Some more info about securing Alpine Linux:
Reduce procfs information to non-root users by appending hidepid to proc:
Contents of /etc/fstab
Reduce procfs and sysfs information by removing read access to some files (may break your system):
chmod 400 /proc/$FILE chmod 400 /sys chmod 400 /sys/$ANY_FILE_IN_DIR
Set as many directories and files as possible as non-executable, read-only.
Consider between AppArmor and SELinux. AppArmor is more convenient to work with, but not as granular since it's path-based. SELinux is label-based, and it is more granular, obvious trade-off is it's more difficult to work with (for most people). linux-lts package only enables AppArmor.
Apply PoLP (Principle of Least Privilege) wherever possible.
Have as little packages as possible on your system, minimalize amount of software on your system.
Get rid of debugging tools.
Use doas and doasedit if root is needed. (I believe doasedit is in the testing repo.)
There is the obvious, which is DISABLE internet access to specific sandboxed/virtualized applications, or disable internet as a whole for a device if practical. (Basically firewalling)
File encryption can be used in tandem with FDE, for granular encryption.
Same could be said for read-only integrity for files/directories.
Unfortunately, there is way too much for securing a traditional Linux server. Not impossible, just a lot left out that could have been done securing traditional Linux based OS'. (BTW it's the same for traditional Unix based OS'...)
Security should be done by default, if not, while you configure your operating system for security, you are already compromised from the start. And more secure users is better than less, for example as you communicate with other secure users you are protected as well, protecting your communications with others.
Follow DM-Verity wiki for an attempt at full verified/trusted boot on Alpine Linux.
At this point, it would be it's own Linux distro