Security Tips

Here is a short summary of security recommendations for the YaST developers.
This is very likely not a full list, feel free to add more tips.

Obtaining the Root Privileges

YaST needs to be already started under the root account, there is no switch
from unprivileged user to privileged one at runtime.

Some modules can be run under unprivileged user but they do not support switching
to privileged user later. That means they usually work only in the read-only
mode and do not allow to change anything.

The result is that there should not be any security problem in this area.

Sensitive Data

Registration codes, access tokens, private keys, passwords (in URLs as well!)
or other sensitive data should never be logged in to the y2log. Although
reading the y2log file requires root access it can be attached to bugzilla
where everybody could read it.

Be careful when logging with .inspect, the result might contain the internal
object data

Temporary Files

Never use fixed or predictable names when writing to the /tmp directory
(or in general any world-writable directory).

If you write to a predictable file the attacker could prepare a symlink with
that name in advance pointing to some other file. Later when the user would
run the code the other file would be overwritten.

C/C++

Downloading

Always prefer HTTPS over HTTP. It ensures you really connect to the intended
server and the communication is encrypted so nobody can read it or modify it.

Do not disable the peer verification, if you still need to do it (e.g.
because of a self-signed certificate) always ask the user for confirmation
and display the certificate details so the user can at least verify the
certificate fingerprint.

SSL Certificates

Downloading and importing a SSL certificate from an insecure source (e.g. HTTP)
does not improve the security, in reality it makes it even worse.

If you need to import a certificate into the system the user should verify the
certificate details (including the fingerprint) and confirm the import.

Package Download and Installation

Always use libzypp functionality (through yast2-pkg-bindings), never download or install the
packages manually.

Running External Tools

The shell injection vulnerability is usually not
a problem as YaST is already running as root and the input comes from the root
user. So privilege escalation should not be possible.

But usually the problem happens when using a file with spaces in the file name or
or the user input contains some special characters like <&%{}>. Then the module
probably does not work as expected or can fail.

Also when executing external tools always use the absolute path to avoid
file not found error when $PATH variable is not set properly or to avoid
running possibly malicious replacements when the path contains the . directory
(which is not recommended).

Another issue might be with the order of the $PATH components, e.g.
/usr/local/bin:/usr/bin prefers the /usr/local/bin which might be also
problematic.

Overwriting the file content might not help on some file systems (see man shred)

A FS snapshot might be created before removing the file

Pass the data on the command line - this is very insecure as it can be displayed
in the ps output so it could be read by anybody on the local machine.
(Exception: This could be possibly used during the initial installation where only the
installer is running and no other user is logged in. But make sure this is not
used in installed system.)

Debugging

The debugging features might also potentially affect security or leak some
sensitive data.

If you need to use a separate log file (not the standard y2log) make sure
the file has root-only access.

Use a directory accessible only to root, otherwise avoid file collisions,
see the temporary files section.

When using a debugger (or any other special debugging features) make sure that
they are disabled by default.

Enable the debugging features only on user request, use a command line
option or an environment variable.

If the tool allows remote control then enable the remote access also only
on request. And if possible by default allow only the local access via the
loopback device (localhost/127.0.0.1).

See more details in the debugging document about the integrated
Ruby debugger support in YaST.

Random Numbers

Linux has two devices generating random data, /dev/urandom (non-blocking) and
cryptographically secure/dev/random (can block if there is not enough entropy).

Similarly in Ruby there is a simple rand() call and
SecureRandom
class providing cryptographically secure methods for generating random values.