User:Pursuable1652: Difference between revisions

From Alpine Linux
mNo edit summary
mNo edit summary
Line 39: Line 39:
----
----


Unfortunately, there is way too much to do for securing a traditional linux server.
Unfortunately, there is way too much to do for securing a traditional Linux server. Not impossible, just a lot left out that could have been done to secure Linux. (BTW it's the same to other Unix based OS'...)

Revision as of 02:19, 16 December 2024

Hello, I'm Pursuable1652 and I helped make these wiki pages:

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):

Some more info about securing Alpine Linux:

Reduce procfs information to non-root users by appending hidepid to proc:

Contents of /etc/fstab

... proc /proc proc nosuid,nodev,noexec,hidepid=2 0 0 ...

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


Unfortunately, there is way too much to do for securing a traditional Linux server. Not impossible, just a lot left out that could have been done to secure Linux. (BTW it's the same to other Unix based OS'...)