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.

1 Like

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.

Dear all!

Has anyone of you tried to apply/adapt some of the measures of Fedora SecureBlue to openSUSE Tumbleweed/Slowroll/Leap?

If so, what in detail and how?

Thank you!

I would like to point to the following:

How do others rate these easy to apply/adapt measures?

The project now has a real project website and some URLs have changed:

I would like to state that I don’t want to promote Fedora generally or secureblue specially (I stay with openSUSE Leap and Slowroll). But I would like to point to some easy to apply/adapt measures. Maybe we can discuss them.

@C7NhtpnK Hardening for what? Services exposed to the internet? If nothing is running, there is nothing to do?

There is no generic solution to your question, you need to describe the end goal of your requirements.

Use MicroOS and a read only filesystem?

The openSUSE Project blacklists some filesystems, because they are insecure, unsupported etc https://en.opensuse.org/SDB:FilesystemBlacklisting

Edit: https://doc.opensuse.org/documentation/leap/security/html/book-security/

Yes, merely why? :wink:

Well, this is true, of course.

Maybe, one has to check first at all, what actually is exposed…

Could be for someone.

Haven’t actually seen this one before, sorry. It’s related to secureblue/files/system/etc/modprobe.d/blacklist.conf (there are quite some more entries).

Has already been mentioned before, but thank you anyway. Should also be regarded, of course.

Well, I mean: no one has to do such things — but can. And there even are special distributions servings these needs. Like the already mentioned secureblue. Or Qubes OS, which is rather special (and not satisfies everyone…). Or Void (Linux), which offers Void Linux supports both the musl and GNU libc implementations, patching incompatible software when necessary and working with upstream developers to improve the correctness and portability of their projects , in comparison to my already pointed hardened_malloc (openSUSE). It also offers runit (instead of systemd) but I don’t want to start flame wars… :wink: (My point is more the hardened_malloc. Even some C programmers care for special malloc handling…) And as mentioned by secureblue, secureblue/articles/kargs holds, please refer to Spectre & Meltdown Checker e.g. There are also people using AppArmor or Firejail or Bubblewrap. And I was told there are even people using SELinux. — Just thinking about… what actually is, what could be, what should be, what is possible? (There actually are easy to apply settings not set by a standard install — but, of course, one could discuss first if really do so and why and what for…)

@C7NhtpnK MicroOS and Aeon use selinux, Tumbleweed will soon, just like sd-boot that is coming etc. It’s an evolving target.

The openSUSE developers try to give the user a generic enough system for them to investigate/tweak/configure as per their requirements, there is no one size fits all…

I use Aeon, it has measured boot with TPM 2.0 , FDE and secureboot is disabled, there is no firewall running, no services running no need for it etc…

My internal LAN has no systems with firewalls running, the internet facing router takes care of that.

I have an on the road laptop, if needed I might start sshd if out in the wild, but most of the time it’s on air-gaped networks.

  • Do you lockdown sudo (run-0 if using)?
  • What services are you running, use nmap from another computer to check.
  • What is the system connecting too, use wireshark (or ss) to capture the traffic and see.

Audit or validate your openSUSE Leap systems with (Open-)SCAP.

https://www.open-scap.org/getting-started/

Follow this guide from SUSE:

Installation of OpenSCAP is very simple:
# zypper install openscap-utils

https://www.open-scap.org/download/

Use up-to-date OVAL files from (open-)SUSE:

and start your “OpenSCAP adventure trip” with this simple shell script on openSUSE Leap 15.6:

#!/bin/bash
################################################################################
# /usr/local/bin/checkSecurity.sh
#
# Sicherheit vom Betriebssystem und der installierten Softwarepakete 
# kontrollieren
#
# GrandDixence, 22.02.2025
#
################################################################################


echo "-------------------------------------------------------------------------"
echo "Start von checkSecurity.sh"
echo "-------------------------------------------------------------------------"

echo " "
echo "Startvorbereitungen..."

# Ins korrekte Verzeichnis wechseln
pushd /tmp

echo " "
echo "OVAL-Dateien herunterladen..."
/usr/bin/wget https://ftp.suse.com/pub/projects/security/oval/opensuse.leap.15.6-patch.xml.bz2
/usr/bin/wget https://ftp.suse.com/pub/projects/security/oval/opensuse.leap.15.6-affected.xml.bz2

echo " "
echo "OVAL-Dateien entpacken..."
/usr/bin/bzip2 --decompress opensuse.leap.15.6-patch.xml.bz2
/usr/bin/bzip2 --decompress opensuse.leap.15.6-affected.xml.bz2

echo " "
echo "Fehlende Sicherheitsupdates suchen..."
/usr/bin/oscap oval eval --report updates.html opensuse.leap.15.6-patch.xml

echo " "
echo "Alle bekannten, offenen Sicherheitslücken suchen..."
/usr/bin/oscap oval eval --report cve.html opensuse.leap.15.6-affected.xml

echo " "
echo "Shellskriptausführung beenden..."

# Ins Startverzeichnis zurück wechseln
popd

echo " "
echo "Ausgaben in den HTML-Dateien:"
echo " " 
echo "updates.html"
echo "cve.html" 
echo " "
echo "im Verzeichnis /tmp mit dem Webbrowser kontrollieren!"

echo " "
echo "Ende von checkSecurity.sh"
echo "-------------------------------------------------------------------------"
exit 0

Use a german to english translator => deepl.com

The inspiration source for this shell script was Ubuntu:

1 Like

At the moment there is only one minimalistic SCAP security guide available for openSUSE Leap 15.
I recommend the usage of the well working SLE15 security guides for any openSUSE Leap 15 installation.

https://www.open-scap.org/security-policies/choosing-policy/

Like SLES, SLED is based on openSUSE Tumbleweed and shares a common codebase (SLE15) with openSUSE Leap 15.

# zypper install scap-security-guide
# oscap info /usr/share/xml/scap/ssg/content/ssg-opensuse-ds.xml
# oscap info /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

For more information about this SCAP security guides for SLE15 see this web page:

https://static.open-scap.org/ssg-guides/ssg-sle15-guide-index.html

Add this lines to the shell script:

/usr/bin/oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_anssi_bp28_minimal --report /tmp/minimal.html /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

/usr/bin/oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_hipaa --report /tmp/hipaa.html /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml
/usr/bin/oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_pci-dss-4 --report /tmp/pci.html /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

/usr/bin/oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_standard --report /tmp/standard.html /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml
/usr/bin/oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig --report /tmp/stig.html /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Start the modified shell script and wait some minutes:

# /usr/local/bin/checkSecurity.sh

Open the report files (*.html) in a web browser:

# firefox /tmp/*.html

Out of curiosity, would this default suffice for a laptop that is often on public Internet connections, or would you personally change something?

I actually just read more about immutable distros and now my interest is piqued and I want to try out Aeon. It is funny because since immutable systems really works differently they also asks the user to think and use their system quite differently. However, security seems to be quite good, if not even better than on traditional desktops and OSes (that of course comes down to how one uses is computer in the first place) but the concept actually also seems all about stability. How is it looking on an Aeon install? From what I read, ports are closed except for sshd, which can be deactivated if not needed. It still feels weird to me, that no firewall is active (even tho I understand that the system is read only, so the attack vector quite small apart from your own files of course).

I just saw that Aeon has no SHA or integrity key check. Any info why? Is it because it is RC3 and not fully released yet? Or should I ask that on their channels directly?