openSUSE:Security Features
Compiler and Toolchain
- glibc malloc heap corruption checking to avoid double-free and similar attacks. These checks have existed in glibc for several years now and are active for all our distributions starting with SUSE Linux Enterprise Server 9.
- The "Fortify Source" extensions in gcc and glibc are enabled for all packages by default (using -D_FORTIFY_SOURCE=2) since SUSE Linux 10.0 and SUSE Linux Enterprise 10. Moreover, since SUSE ALP, all packages are built by default using -D_FORTIFY_SOURCE=3. This extension brings:
- Compile buffer overflow checking for various C string / memory functions. On a overflow of a buffer that is already provable at compile time a warning is emitted by the compiler and caught by our build processes.
- Runtime buffer overflow checking for the C string / memory functions for destination buffers whose size is known at compile time. An overflow here triggers a controlled abort of the program.
- Exploitation of format string problems trigger a controlled abort of the program.
- Specific warnings on missing return value checks of dangerous library functions.
- Runtime stack overflow checking using -fstack-protector is used in some critical packages in SUSE Linux 10.1 and SUSE Linux Enterprise 10 and enabled by default for all packages starting with openSUSE 10.2.
- Marking stack and heap non-executable to make NX possible is done for nearly all packages for some time now.
- -z relro is enabled by default since SUSE Linux 10.1, which makes attacks on specific ELF sections no longer work.
- While a number of selected binaries were built as Position Independend Executables (PIE) for a while, on May 2017 Tumbleweed was switched to enabling PIE per default for all binaries. SUSE Linux Enterprise 15 and openSUSE Leap 15.0 and later have all binaries built with PIE enabled.
- Stack Clash Protection ( -fstack-clash-protection) is enabled in SUSE Linux Enterprise 15 and later and also on Leap 15.0 and later, and for freshly released updates in SUSE Linux Enterprise 12 and openSUSE Leap 42.3.
Kernel
- Hardware based NX (No eXecute, also known as DEP) support is enabled for Stack and Heap since SUSE Linux Enterprise Server 9 on:
- all AMD64/EM64T processors.
- on x86 machines using the "bigsmp" or "pae" kernel and the processor being able to support the NX bit.
- We do not include Software NX at this time, since it is not in the mainline kernel and likely never will be.
- Address Space Randomization is used for the stack and library mappings since SUSE Linux Enterprise 10 and SUSE Linux 10.1.
- Address Space Randomization for PIE binaries and their heaps since openSUSE 11.1 and SUSE Linux Enterprise 11. (randomize_va_space=1)
- Address Space Randomization for binaries seperated from heaps and for the VDSO segment starting with openSUSE 12.2. (COMPAT_VDSO and COMPAT_BRK turned off, randomize_va_space=2)
- "ExecShield" and "PAX" contain several features including the ones listed above. This means that we implement parts of the "ExecShield" and "PAX" functions already at this time.
AppArmor
We included the Mandatory Access Control System AppArmor to confine potentially endangered applications.
SELinux is enabled in the kernel, though there is no default policy provided.
Firewall
Since SUSE Linux 9.3 the iptables based SuSEfirewall2 is enabled by default, including a very restrictive inbound filtering.
nftables is available for installation starting with 13.2 onwards.
Starting with openSUSE 15 SuSEFirewall2 has been replaced by firewalld as the default firewall package.
Software choice
We chose to run only a minimal set of daemons in the default configuration. Only the following are listening to the network:
- SSH daemon
- portmap daemon
- avahi/mDNSResponder
- cups print server
All of them are blocked by the firewall by default though.
setuid binaries
Setuid/setgid binaries are:
- kept to a minimum. We try to replace them by more secure methods of user - root privilege passing or even get rid of them at all.
- new ones are required to be source audited by the Security Team, old ones are audited again after some time.
Source code audits
System services, setuid binaries, PAM modules, DBUS Services and other security relevant software is audited by the security team and the findings reported to the upstream maintainers and fixed.
YaST Security Center and Hardening Module
The YaST module Security Center and Hardening offers a central area to easily configure security-related settings for openSUSE. It is used to configure security aspects such as settings for login, password creation, boot permissions, user creation or for default file permissions. To launch it: YaST › Security and Users › Security Center and Hardening.
For more information: YaST Security Settings Module Documentation
Systemd hardening effort
systemd offers various options to harden services. Full details are available here, with most of the options set here described in the 'Sandboxing' section.
The security team would like to add more of these hardenings to the .service files of the distribution. This effort is tracked in this bug.
As a first step we try to get mitigations activated that have a low chance of breaking user setups:
- ProtectSystem: 'full'
- ProtectHome: 'true'
- PrivateDevices: 'true'
- ProtectHostname: 'true'
- ProtectClock: 'true' (implies DeviceAllow=char-rtc r, which implies a restriction on all other devices, so breaks e.g. everything trying to access a disk device without further DeviceAllow= lines)
- ProtectKernelTunables: 'true'
- ProtectKernelModules: 'true'
- ProtectKernelLogs: 'true'
- ProtectControlGroups: 'true'
- RestrictRealtime: 'true'
If you see a different set of options in your submission your package either already carries hardenings that we won't modify or we figured out based on the package description that some hardenings don't apply (e.g. ProtectClock doesn't make sense for a daemon setting the time).
There are many hundred service files in openSUSE Factory. To adjust them at scale a script is used that adds these hardenings and submits them. If they break your package please feel free to decline the submissions. We would ask you to narrow down the set above to something that works for your package.
We also appreciate suggestions on how to do this in a better way as this is also an experiment for us.
FAQ:
- Support in older releases In systemd < 244 some of these options are unknown and will produce warnings. Archie Cobbs provided this snippet to disable this on older releases. We will try to add this to the logic that adds these hardenings, but fiddling with spec files all over Factory is a bit tricky. If you want to make sure that your users don't see these warning as something like:
# Avoid "Unknown key name 'XXX' in section 'Service', ignoring." warnings from systemd on older releases
%if 0%{?is_opensuse} && 0%{?sle_version} < 150300
sed -r -i '/^(Protect(Home|Hostname|KernelLogs)|PrivateMounts)=/d' src/unit/fonehome.service
%endif
- Will you send this upstream/Why don't you sent this to upstream? We're hoping for your help here. We'll be submitting this for hundreds or packages in an automated fashion. Some of these service files are in our own packaging, some are upstream. ATM we don't have a mechanism that would allow us to scale this so we can bring the change to upstream directly. It would be appreciated if you could work with upstream so that other distros/users also benefit. Once this has been in use at openSUSE for a while it shouldn't be to hard a sell
- Can we make some of them the defaults in systemd and only deviate where needed? That would also require a lot of submissions and has a high chance of breaking a lot of packages at once. With this approach we can work over time without a big breaking change at once
Misc
crypt(3) algorithm: DES until ..., Blowfish since ..., SHA512 since ...