openSUSE:Package security guidelines

tagline: From openSUSE

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 security team has reviewed the source code and granted explicit permission. To request an audit for setuid binaries a bug report for the security team should be opened. 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 includes the 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 shipping 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.

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.