Measures to harden an openSUSE install and to run an openSUSE system securely

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.

1 Like

@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…)

@C7NhtpnK:

There’s also the openSUSE equivalent document for Leap (maintained by SUSE staff members) → <Security and Hardening Guide>

  • At a quick glance, the differences seem to be:
  1. The publication date:
    openSUSE: June 10, 2024
    SUSE: December 05, 2024

  2. The SUSE SLED document has a “Regulations and compliance” chapter.

  1. The openSUSE Leap document has a “SELinux” chapter.

1 Like

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

I do follow most of those ideas. (Thanks again to @bmwiedemann)


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:

  1. SUID/SGID files
  2. World-writable files
  3. Orphaned or unowned files

Results:

  1. OK so far I do understand the output.
  2. This indeed throws quite a lot of items: I modified them, then.
  3. Unowned Files: OK so far. Orphaned packages: there was actually one item from Leap 15.2 left! Wondering how…

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 .

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.