I'd stick to having a unified vfat boot+EFI partition mounted at /boot. systemd-boot is the simplest bootloader and it doesn't support loading it's config and kernels from non-vfat partitions anyway. Just make a 5GB boot+EFI partition so you can store plenty of kernels or even a recovery image.
For security, I recommend following Madaidan's Insecurities Linux hardening guide, it has good explanations of most of the same sysctl options and kernel flags. [1]
The only option that may be best left disabled is `init_on_free=0` since this is one of the few options that has a measurable performance impact (besides the normal spectre/meltdown related options).
For NTP, systemd-timesyncd works fine and is probably the default for any modern distro.
Desktop security is still a nightmare, if you use a Wayland based desktop environment and Pipewire for audio/video streams then maybe in 10 years you'll a secure clipboard and no unauthorized keyloggers.
If we use a web browser as an example, what are the odds that a compromised website is going to try to exploit the browser itself vs. exploiting an external sandbox application? Clearly the former. Sandboxing a web browser will prevent many more classes of attack than it exposes you to.
Also worth noting that the suid binary you mention will refuse to run at all if the executing user isn't in its whitelist. It's not like you can pop a shell on some ftp user and run firejail as root.
Works just fine on my Dell Precision 7540. Tried briefly to get GPU passthrough to work but failed. I lack the time to seriously try. Otherwise, it works great.
Why are most default homes setup with a mode other than 700 directories 600 files? I know, it is because of the default mask system wide, but it seems to make sense to do this to homes, unless I am missing something?
Before UPGs, every user would have `users` or something similarly generic as their primary group, and it was intentional that everyone's homedir allowed read access to that group for the purpose of sharing files between users.
With UPGs, every user will have a bespoke primary group, so having group access to the homedir is not a problem. Whether the distro still keeps the other-readable bit is up to the distro. For example, OpenSUSE used to be in the pre-UPG 0755 camp, but switched some time ago to the UPG 0700 camp.
The default UPG usage and homedir permissions are controlled by USERGROUPS_ENAB and HOME_MODE in login.defs (under /etc or /usr/etc, depending on your distro).
> For example, OpenSUSE used to be in the pre-UPG 0755 camp, but switched some time ago to the UPG 0700 camp.
When was this? 15.4 doesn't have user per group by default, nor does it have 0700 on $HOME by default. I have several fairly recent installs around I checked. Something in Tumbleweed perhaps? My last Tumbleweed install was last year sometime and does not have user per group nor 0700 $HOME.
I got around to checking, and turns out that my Tumbleweed installs are creating new users with 0700 home directory now. I didn't think to try creating a new user in my earlier checks, I just checked the existing users I've had. New users are still 0755 home directories on 15.4 though.
It's great to have guides like this, but there are a lot of recommendations in here, and I don't understand the implications of all of them, individually or together.
The author seems opposed to disabling security mitigations for performance reasons, but what are the trade-offs? What if you use your workstation for 3D rendering or machine learning, and you really do want to maximize the performance of your hardware?
Most of the options don't have much or any performance impact. The few that do e.g. the spectre/meltdown related ones provide improve security far more than they impact performance on a recent-year CPU. If these security options make or break your ability to do certain kinds of work - then you'd probably benefit most from using a more modern and faster CPU.
If anything some of these options are more likely to break the occasional application completely e.g. some applications use user-namespaces.
linux is such garbage security-wise that it had to be a niche "hardening patch" to make processes not be able to see the argv of other processes. this normally wouldnt be a problem, except for the fact that linux and its proponents claim that it and other unixes have ultra secure user separation facilities
I'm not sure who's ever claimed that. From the get-go, Unix design philosophy was simplicity, and it was in opposition to Multics and other complex multi-user OSes that had a lot of security and compartmentalization baked-in.
I remember during my first job discovering that SunOS had C2 security available and trying to enable that, then realizing it messed up a lot of stuff and trying to disable it by hand... what a nightmare. I was fascinated by compartmentalized security type stuff but I really had no idea. That sort of security will really hamper user productivity and collaboration. You need to spec it out, because otherwise an OS is going to default to the latter.
