User:Pursuable1652

From Alpine Linux

Hello, I'm Pursuable1652, I like scripting, some different types of development, modifying hardware/software, like learning about home-servers or networking (or general server administration)/(homelabbing), also like learning some security and privacy, and more (I'm very passionate about computers), and I helped make these wiki pages:

Working on apparmor profiles for init-services for openrc, MUST be ran in initramfs or at least before running openrc as PID1... (There is systemd service apparmor profiles available here: https://github.com/roddhjav/apparmor.d, but I do not see openrc init service apparmor profiles publicly available anywhere...)

It is possible to run a read-only image (immutable?) (since it is immutable, must upgrade using an server providing upgrade files, and updating init script to call to update system.) Linux system without root access (use system without doas, sudo, or becoming root in any other way), by setting your user a part of docker group (AND possibly a lot more). But it is challenging since I had to create a power service (because I want to control power of server without root) ran as an init service, and call back to it (using a non-root user) to a /run/*.socket, since I don't have root access.

Possible to run system with dm-verity enforcing a read only system. The read only image ideally should have [usr,sbin,bin,lib] as read-only. everything else (kernel virtual filesystems: [dev,proc,sys,tmp,run]) and (user writable directories [var,etc,home]) are just empty directories in the erofs image. (They're empty because you're supposed to mount the file systems to those directories..)

Using dm-verity and read-only images (basically immutable distro?), would benefit from an upgrade server. Basically a server that provides the read-only images, and any other files needed to upgrade a Linux system. This could be similar to setting up an APK repo for alpine Linux, but instead just putting your compressed (tar'ed?) readonly images plus other files in the web directory, so other servers/devices can upgrade from it.

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.

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

Set as many directories and files as possible as non-executable, read-only. And mount file-systems as non-executable and 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/VLAN'ing)

Obvious make full backups

File encryption can be used in tandem with FDE, for granular encryption.

Same could be said for read-only integrity for files/directories.

Always use HTTPS to download repository packages for your system.

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

Retrieved from "https://wiki.alpinelinux.org/w/index.php?title=User:Pursuable1652&oldid=28785"