User:Pursuable1652: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| Line 38: | Line 38: | ||
Set as many directories and files as possible as non-executable, read-only. | 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). | |||
---- | ---- | ||
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'...) | 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'...) | ||
Revision as of 15:18, 16 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).
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).
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'...)