Home Wiki > openSUSE:Package security guidelines
Sign up | Login

openSUSE:Package security guidelines

tagline: From openSUSE

The security guidelines regulate all the details of secure packaging for the openSUSE distribution. To avoid unpleasant surprises packages have to adhere to certain security policies. Exceptions from the common security policies have to be discussed with and approved by the openSUSE:Security team.

Daemons

  • installation of a package must not activate any daemon. That means for example init scripts must not be insserv'd in %post, xinetd files must contain 'disable = yes'.
  • daemons should run under an unprivileged user id. That usually means the package has to create the user in it's %pre section. Daemons should avoid running as root and must not use the 'nobody' user. It's fine to use group 'nogroup' though.
  • daemons should be restarted if the package was upgraded so security updates take effect immediately
  • daemons that open tcp or udp ports or otherwise receive input from potentially untrusted networks should receive an audit from the security team prior to inclusion in the distribution.

Setuid Binaries

Packages are not allowed to include setuid/setgid binaries unless the SUSE Security Team has reviewed the source code and granted explicit permission.

To request an audit for setuid binaries, open a bugreport assigned to security-team@suse.de and/or send an e-mail to security@suse.de.

The bug report should include the exact location of the source code, the affected files and an explanation why the setuid bit is required. If the audit turns out positive, the security team will include permission settings for the new files in the 'permissions' package. The build system will reject packages with setuid binaries that are not listed in the permissions package.

In general having a setuid bit by default requires good reasons. Most of the time it's better to ship without setuid bit but including instructions how to modify /etc/permissions.local instead if needed.

setuid binaries need to be packaged specially. See the %verify_permissions macro for examples.

Packaging setuid binaries

Security-relevant permissions are handled via /etc/permissions* on openSUSE. Read the files /etc/permissions* to learn about the basics.

If you want to create a package with suid programs:

  • Add a Requires(post): permissions header to your spec file.
  • In the %files section, define the attributes of the files listed in your permissions files as they are defined for permissions.secure. Instruct rpmverify to not check ownership or permissions.
  • Add a %post scriptlet that sets your package's permissions according to the system's current security level.
  • Add a %verifyscript scriptlet that checks your package's permissions according to the system's current security level.

Because the above contains a few non-obvious details, here's a stripped down example:

[...]
PreReq:         permissions
[...]
%if 0%{?suse_version} >= 1120
%verifyscript
%verify_permissions -e %_bindir/mysuidprogram
%endif

%post
%if 0%{?set_permissions:1}
    %set_permissions %name
%else
    %run_permissions
%endif

%files
%defattr(-,root,root)
[...]
%verify(not user group mode) %attr(0711,root,root) %_bindir/mysuidprogram
[...]

To do temporary builds in your home project:

  • Use the package-specific permissions that can be defined through files in /etc/permissions.d/.
  • Create permissions{,.easy,.secure,.paranoid} files for your package. permissions is used if no file permissions.* matching the system's current security setting is found. As a rule of thumb, permissions.easy should contain permissions as installed by make install, permissions.paranoid should remove all suid bits (even if this breaks functionality), and permissions.secure can be something inbetween.
  • Add these permissions files as sources to the spec file, and have %install install them in %buildroot/%_sysconfdir/permissions.d/packagename[.suffix].
  • In order to avoid rpmlint's error messages about disallowed permissions files, create a file packagename-rpmlintrc containing the line setBadness('permissions-unauthorized-file', 333), and list it as a Source in your spec file. (Modify the "333" if you have fewer or more than 3 disallowed files.)

Please note that all these workarounds must be removed before the package is submitted to the openSUSE distribution.

World Writable Directories

In general world writable directories should be avoided. If a package desparately needs world writable directories the same rules as for setuid binaries apply.

Group Writable Directories

There is no build check for directories writable by some special group and no review by the security-team needed. However packagers should be aware that directories inside group writable directories cannot be packaged securely and may allow members of the group to elevate their privileges to root. In other words never package directories inside group writable directories.

Firewall Settings

No package is allowed to modify SuSEfirewall's configuration file. An exception is granted for the yast2 firewall module. Any other application must use the interface offered by the yast2 firewall module to change firewall settings. Changing the firewall settings must always require explicit confirmation of the user.

DBus Services

Programs that offer services via the system DBUS must receive an audit from the security team prior to inclusion in the distribution. In general the same rules apply as for any other daemon.

PolicyKit Privileges

Programs that carry out privileged operations on behalf of the user (such as e.g. changing the clock) should define a PolicyKit privilege which a user is required to posses for a specific action to be carried out. Use of PolicyKit privileges has to be audited by the security team prior to inclusion in the distribution

Passwords

Packages must not be preconfigured with fixed passwords, certificates etc. Instead the user must be forced to set a password prior to first usage.

Use Of Cryptography

In general packages must not implement their own cryptographic algorithms but should use either of the following implementations:

  • mozilla-nss (preferred)
  • openssl
  • gcrypt
  • gnutls
  • kernel crypto interface (kernel modules only)

Preferably encryption and hash algorithms should be configurable and set to currently considered safe algorithms (e.g. aes, sha1). Use of MD5 as cryptographic signature is not safe anymore.

Packages should not ship their own set of trusted x509 certificates. Instead /etc/ssl/certs should be used as fallback.

Audit Bugs for the Security Team

A number of security related program features require a whitelisting by the SUSE security team, before they can be packaged and submitted to Factory or any [open]SUSE product. Among these are the following items:

  • binaries installed by the package carry a setuid or setgid bit. This allows regular users to run the binary with elevated privileges. These kind of binaries are difficult to implement correctly in a secure way. Therefore the security team would like to avoid adding any additional set*id binaries to the distribution. If there is no way around it then a thorough review is necessary.
  • new D-Bus services are installed by the package, that can be activated dynamically or via systemd units. D-Bus services often run as root and expose interfaces to regular users. Therefore these cases are also security sensitive.
  • systemd services are required to be enabled by default. Only a small number of packages is currently allowed to be enabled by default right after installing it. Other packages need to be enabled explicitly by the user. New default-enabled systemd services need to be reviewed as well.
  • new PAM modules are installed by the package. They also require a security team review. Badly implemented PAM modules may cause user authentication to always succeed or otherwise badly influence security.
  • new polkit rules are added. Polkit is an authentication framework that allows to authenticate individual operations instead of just allowing all or nothing. While this sounds (and is) good it still needs to be done right in each implementation. Therefore this also requires a code review.

If you add one of these items to your package and want to add the package to openSUSE:Factory then an rpmlint error or warning will appear. If your package is affected by any of these restrictions then please open a bug in bugzilla.opensuse.org, assign it to security-team@suse.de and use the summary line AUDIT-0: [package-name]: [topic]. A member of the security team will then take care of the review and perform the necessary actions.

rpmtlint Errors in Packages

For reference, examples of the possible rpmlint error messages that can occur in a package are listed in the following table:

Category Error Messages
Polkit Privileges
lightdm.x86_64: E: polkit-unauthorized-privilege (Badness: 10000) org.freedesktop.DisplayManager.AccountsService.ModifyOwn (yes:yes:yes)
lightdm.x86_64: E: polkit-untracked-privilege (Badness: 10000) org.freedesktop.DisplayManager.AccountsService.ModifyAny (no:no:no)
D-Bus Services
NetworkManager-libreswan.x86_64: W: suse-dbus-unauthorized-service /etc/dbus-1/system.d/nm-libreswan-service.conf
PAM Modules
pam_oath.x86_64: W: suse-pam-unauthorized-module pam_oath.so
Set*id bits
firejail.x86_64: E: permissions-file-setuid-bit (Badness: 900) /usr/bin/firejail is packaged with setuid/setgid bits (04755)

Suppressing rpmlint errors for home and devel Projects

The rpmlint errors that are supposed to protect openSUSE:Factory from security sensitive packages also apply to your home and devel projects. This can block you from developing a package or using a package that is not supposed to be actually submitted to openSUSE:Factory.

You can suppress the errors by adding an rpmlintrc file to your package named $PACKAGE-rpmlintrc and containing a line like setBadness('polkit-untracked-privilege', 0). Packages containing such suppressions must not be submitted to openSUSE:Factory, however. If you want to submit to Factory you need to open an AUDIT bug and wait for the whitelisting by the security team.

AUDIT Bug Priorities

Due to the amount of audit bugs and limited resources we use the following prioritization categories in Bugzilla:

Priority Meaning
P0: Customer Critical Situation
  • A critical situation requiring immediate attention
P1: Urgent
  • Items blocking a product release so it may not be released
P2: High
  • Items requested for an upcoming product release
  • Items affecting current development or testing
P3: Medium
  • Items for packages that are in SLE or will be
  • e.g. anything with a SLE feature request or bug
P4: Low
  • openSUSE only items with support by release team or general interest
P5: none
  • openSUSE only request without support by release team