Dear all,
in AMA: openSUSE dev for 15 years I (@C7NhtpnK ) asked @bmwiedemann for specific measures, see below.
Do you guys have more ideas, more input on this? — Interested in and thankful for further ideas and input.
Dear all,
in AMA: openSUSE dev for 15 years I (@C7NhtpnK ) asked @bmwiedemann for specific measures, see below.
Do you guys have more ideas, more input on this? — Interested in and thankful for further ideas and input.
I use the SUSE website documentation for most things on openSUSE.
@Capistro Thank you!
I’ve seen that document before. It’s quite a lenghty document. Are there any specific measures you would like to point to?
(And some measures are still to be discussed: like umask
… I myself modified umask
— but there is not ONE perfect umask
…)
There’s also the openSUSE equivalent document for Leap (maintained by SUSE staff members) → <Security and Hardening Guide>
The publication date:
openSUSE: June 10, 2024
SUSE: December 05, 2024
The SUSE SLED document has a “Regulations and compliance” chapter.
Of course it is quite lengthy. It suggest many thing for many environments. First thing is to asses for yourself against what threats you want to protect your system/data.
E.g. umask
is mainly a to automate the protection of data of a user against unauthorised access of other users on the system. I say automate, because a user can of course set the permissions of each and every of his/her files as needed, but setting umask
will use a default permissions setting for every created file, again to the need of the user, so he may have to do less changes to permissions manually.
Aa said umask
is typically a user mechanism and when you say
I assume you did that as a user. It is not really about hardening “the system”. that is a task of the system manager (as root
).
@dcurtisfra Thank you!
Oops, I recently noticed I was the document for Leap instead of SLE which I have read.
Thank you for the short comparison. Yes, they seem quite similar. The additional part of the SLE document does hardly not hold to me as a personal user.
@hcvv Thank you!
Well, it’s indeed for root
. I wrote “myself” because I personally did this modification manually (after system install).
- For security, I use disk-encryption for /home and ensure secrets (e.g. VPN creds) are stored there.
- all my ssh keys have a passphrase added. Some need a FIDO2 USB-stick to be touched (Yubikey, Nitrokey, Google Titankey).
- I try to enable 2FA on relevant websites and avoid SMS+email modes. The good ones are TOTP/FIDO2/Passkey.
- I use a different password on every website using a variant of bmwtools/pwhash at master · bmwiedemann/bmwtools · GitHub
- I try to stick to packages from the main openSUSE repos so I know those went through a review.
- In Firefox I use the NoScript, Multi-Account-Container + Sticky-Window-Container addons, so work+banking cookies are kept away from other tabs.
- I use podman instead of docker, when possible. It runs rootless by default.
- On my server, everything runs with KVM under its own user with GitHub - bmwiedemann/bmwvm-tools: scripts to start/stop/manage VMs so even when there was an exploit in KVM, there is still some isolation.
I do follow most of those ideas. (Thanks again to @bmwiedemann)
- a different
umask
(mine is0077
)- use of AppArmor (it is preinstalled, but what about extra profiles to be enabled manually?)
- use of SELinux (it is not preinstalled with openSUSE, but with Fedora I guess)
- use of FireJail (some people use it and recommend it strongly)
- use of FlatPak to use their sandbox
- DisplayManager (DM): rootless or not? (I use LightDM which is NOT rootless.)
- delete/disable certain packages/apps/services/daemons? if yes: which?
- further possible measures?
I do follow some of them: SELinux and FireJail not yet (and thinking about if yes indeed).
I wonder whether running X11 NOT rootless is a significant risk. It has been this way for decades… The regarding discussion just came up recently.
I did again read Security and Hardening Guide (Leap) and Security and Hardening Guide (SLE).
This time I checked:
Results:
a different
umask
(mine is0077
)
Well, acutally I am the single and only user of my system. So it’s not really necessary I guess. But it is as a matter of principle .
Well, it’s indeed for
root
. I wrote “myself” because I personally did this modification manually (after system install).
First, we are trying to understand what the system “sees” and “does”. The system does not know you (from your point of view “I” or “myself”). The system only knows users. Thus describing actions on the system as “done by me” is confusing. You should explain which user does things.
I am not sure what root
did to "change the umask
, because you do not explain that, but be aware that that can be tricky, because root
does all sort of things, like installing software. And installing software normally leads to all files that are installed getting the permissions that are carefully thought out by the designer and packager of the software. When then some of those permissions are switched off, you could create surprising results.
umask
is really only something that helps a user in managing the permissions of his/her files.