openSUSE:Security use cases

This page is a collection of use cases for the administration of a local system

Introduction

A desktop user of the openSUSE distribution often wants to do tasks that need root privileges and the desktop environments have been enhanced to not require the admin password in every case, using tools like polkit. Still, the question which tasks exactly should require what kind of authorization can be discussed in a heated way.

This page should help to come to a documented default setting of openSUSE. As a first step, it lists and comments on use cases.

Root password

The question is: when exactly should the root password be required — and how often?

Here is a proposal:

The root password is needed as validation and visual indication that the action:

cannot be undone
risk the integrity of the system
affects other users

From a usability and convenience side, we should consider that the user does not want to enter the root password for routine tasks that happen often.

Use cases

Time

Description: Setting of the system time.

Should not be needed if system is setup with ntp.

Security evaluation:

Changing time back could set the time before SSL certificates expire or GPG keys expire.
Log files: changing the time gives strange order, might make it easy to remove stuff
affects other users

Timezone

Description: Setting of the timezone.

Security evaluation:

Not a security problematic operation, but having it done on a multiuser system would confuse the other users.

Idea would be to adjust timezone handling to be per-user.

Options:

Use TZ variable — needs a restart of application/desktop, so not a useable
Change glibc to read ~/.localtime before reading /etc/localtime. Andreas Jaeger is currently evaluating this.

GPU for calculation

Description: Jan wants to use his Radeon or Nvidia graphics card for numeric calculation besides showing his desktop.

Security evaluation:

Giving blanket access is problematic, as users have full access to the display.

This needs access to a file in /dev, Jan can be added to the group video which has access to it. As this change will occur seldom, GPU compute interested people can do this manually. (The NVIDIA device file is not handled by udev as it is a non-GPL driver, so modern ACL management is not available.)

Accessing the network (Ethernet, WLAN, UMTS)

Description: Jan is travelling and wants to access the Internet in his hotel.

Changing network settings to match the hotel's network is sensible and should be doable.

Security evaluation:

Even a user-specific network change affects the whole system, not just one user as networking is effectively global.
Difference between a laptop user traveling about and a multiuser desktop system (at a company/school/etc.) is hard to detect.
- standard networkmanager actions like switching between wired and wireless network should be detectable, and be allowed without root password.
Lockdown methods should be available for high-security laptops.

Changing firewall (setting to private/public)

We have predefined firewall settings whether a network is connected to a private (trusted) or public (untrusted) network.

The user can change for each network interface whether it is public or private.

Security evaluation:

This change affects the whole system.

Querying/Changing of display brightness

This was observed to produce popups for rootpw in the past, while working on text consoles (which makes the X11 session an inactive session which has less permissions).

Handling of external hardware

Printer

Security notes:

Printer setup is something that affects all users. When a printer is set up it means that by default all users use the printer via its particular setup. There is no such thing as "private printer setup" where a user can set up a printer only for his own usage so that his setup is visible and usable only for him.
PPD files and printer filters/drivers run as user "lp" and can execute arbitrary code. Who is allowed to set up a printer is allowed to provide a PPD file so that he is allowed to execute arbitrary code as user "lp".
A user who is allowed to set up a printer is allowed to specify printer filters/drivers so that he is allowed to let the printer print as usual but additionally send a copy of what is printed to any other destination.
A user who is allowed to set up a printer is usually also allowed to announce his printers in the network and do "print job phishing".

Links:

Adding a new local printer

Use case: Jana buys a new printer and attaches it directly to her laptop via USB. She wants to start printing right away.

Automated USB printer configuration works today under GNOME via the package udev-configure-printer if there is a PPD file for the printer (plus matching printer driver) already installed that matches the autodetected USB printer model name.

Notes:

If no PPD file is available that matches the autodetected printer model name, the user could select another PPD file in a printer setup tool. But running a printer setup tool usually requires the root password because providing an arbitrary PPD file makes it possible to execute arbitrary code as user "lp".
If printer drivers are missing, they need to be installed.
Some printer drivers are only available from the printer manufacturer and thus not part of the openSUSE distribution. In particular, non-free printer drivers or non-free printer driver software modules like the non-free plugins for the HPLIP driver.

Links:

Using a remote printer

Usecase: Jana takes her laptop to her office and wants to print on one of the office printers.

If there is a CUPS server in the office network that advertises its printers via so-called "CUPS Browsing", the cupsd on the local system (if the UDP ports for CUPS are open in the firewall on the local system) would recognize the printers so that there is nothing to set up for the user on her local system.

Printing in a Windows network: Usually this means to access a printer device via a SMB printer share. In this case, the local (client) system must usually submit ready-made printer specific data to the SMB share. Therefore, on the client system, a printer driver must usually run and that means the user must usually add a new local printer on her local system for printing in a Windows network.

Links:

Scanner

Usecase: Jana buys a new scanner and connects it via USB to her system and likes to scan.

Automated USB scanner configuration works today via the package sane-backends-autoconfig if the scanner is well supported by a scanner driver in the package sane-backends.

Otherwise, the user could run the YaST scanner setup tool. But running a YaST setup tool requires the root password.

Notes:

Nowadays, scanners are often one unit in an all-in-one printer/scanner/... device so that from the user's point of view "set up an all-in-one device" means to set up all its units (i.e. a user expects to be allowed to set up both the scanner unit and the printer unit). From the system's point of view, each unit is a separate device (with separate permissions).
Some scanner drivers are only available from the scanner manufacturer and thus not part of the openSUSE distribution. In particular, non-free scanner drivers or non-free scanner driver software modules like the IScan driver plus modules from Epson (formerly Avasys).

Links:

http://en.opensuse.org/SDB:Configuring_Scanners

External storage like USB stick

Storing files

Usecase: Jan has an external harddisk and likes to store his digital photos on it.

Currently this is automatically mounted.

Usecase: Jan has an external harddisk and likes to store his digital photos on it, mounting it on a multiseat system. Janett is also logged into that system but the interactive console is inactive, and John has a concurrently-active session.

* Only Jan and John should get device notifications.
* John's notification should be hidden when Jan mounts it with exclusive write access.

Usecase: Jan has an external harddisk and likes to store digital photos on it. Janett is also logged into that system on another interactive console, and would also like to store digital photos on it. Jan lets her.

* Jan should be able to mount the device world/group-writable.

Usecase: Jan has an external harddisk and likes to store his digital photos on it. Upon logout, he forgets to unmount. John logs in later, and would like to safely unmount the external harddisk.

* Unmounting filesystems mounted by other users should require proper access rights, but still be possible from DEs.
* /etc/fstab filesystems should be excluded

Create bootable install stick from ISO

Usecase: Peter would like to create a USB stick from .iso file to install openSUSE on a machine that has no optical drive, i.e. "dd if=file of=/dev/something"

Reformatting external drive

Usecase: Jane just bought an external USB drive and wants to store a large file, but gets an error due to a filesystem (drive pre-formated with FAT32) limitation.

Usecase: Paul has as pen-drive that is currently formatted with a filesystem only supported on Linux and wants to share some files with his friend using a different OS. He needs to reformat the pen-drive with a commonly-known FS.

USB network stick (UMTS, WLAN)

With NetworkManager: The card is automatically configured and available for usage. See above under "Accessing the network (Ethernet, WLAN, UMTS)" for further details.

Camera

works fully automated without root password for years now

Handling of software packages

Update installed software packages

Usecase: Jan gets a notification that important updates for software packages are vailable. He wants to install them.

Security evaluation:

This is a system-wide action.
Not installing security updates is bad.

Note that this is a regular operation.

Install new software packages

Security evaluation:

Installation from trusted repositories should not introduce extra risks.
For package installation, a package from the update repo needs to be installed, it should not be possible to install an old version with a known vulnerability.
Installation of a locally downloaded package means installing an untrusted package and should need root privileges.
New packages may conflict with existing packages, which could negatively affect other users

Adding/removing repositories

Usecase: Jan wants to install new software, for this he needs to add another repository.

Security evaluation:

Adding repositories is a system-wide action.
This allows adding of untrusted or comprised repositories.
Removing would allow removing the update repository - to keep vulnerable programs from updating.

Delete software packages

This is similar to installing new packages.

Security evaluation:

This is a system-wide action.
Removing packages can break the system (but packagekit does not allow e.g. removal of glibc since it does not handle conflicts)

Accessing optical media CD/DVD

Play Music CD

Joe inserts his favorite CD and wants to play it.

Users should be getting an ACL entry for the /dev/sr* node already, and thus can control autonomous and/or assisted playback.

Watch A Movie

Mary inserts a DVD and wants to watch a movie.

The DVD's filesystem is automounted (see above) and thus, player software can be pointed to the mountpoint to start playback. Also, the /dev/sr* node has appropriate ACL entries so player software directly-reading the disc can also function.

Access Data on CD/DVD

Pamela wants to read a file that is stored on CD given to hear by a friend.

Writing to NTFS

Jan has installed openSUSE in dual boot with a version of the Microsoft Windows operating system using the NTFS filesystem. He wants to edit/delete/create files on the NTFS partitions from openSUSE but he can't - unless he works with root permissions or figures out how to properly edit the relevant entries in /etc/fstab.

Security evaluation:

Ntfs-3g should be quite mature by now, and the risk of corrupted NTFS filesystems should be extremely low.
There might be some conceivable risk of data loss on some corner-case multiuser system, but the sysadmin should handle this situation himself.

Link:

https://features.opensuse.org/310229

Writing to an NTFS removable drive

I'm unsure if the above restrictive permissions are also applied to removable devices such as USB sticks and external hard drives with NTFS by default. Does anyone know?

Roles and profiles

We like to make installation and setup of a system as easy as possible. For special cases, the administrator needs to be able to fine tune these. A number of basic roles can be considered.

Let's first look at same usage scenarios:

Single user machine:
- Administrated by user via root access (no convenience): This is Matthias, he prefers to switch explicitely to root for doing administrative actions and happily enters his root password.
- Administrated by user in a convenient way: This is Frida, she prefers to enter the root password only in very rare cases.
Multiple user desktop machine: This machine is used by one user at a time but has an extra administrator
- Locked down access: Paul works in a government agency and his machine is administrated completely by the IT department. Paul cannot even read data from an USB stick.
- Lazy admin: Ron has set up a laptop so that his daughter Daniela can use it. Daniela should be able to use the laptop wherever she goes and do her normal tasks (printing, accessing internet) and Ron will take care of keeping the machine updated and secure.
Server machine:
- Administrators with same rights
- Administrators with different roles, e.g. mail only administrator, apache administrator (this is related to Lazy admin)

On a machine there might be different users with different roles. What roles can we define from these scenarios for openSUSE?

Normal user: The normal user access to the machine and will travel with it. So, she needs to be able to change internet connection, access new printers, update packages. The user might have the root password — or asks the admin to type in the root password when needed.
Guest account (restricted account): The admin will give access to the machine to somebody untrusted, e.g. a visitor at home, a user at a public machine (university/school). The user should be able to use the machine in the existing environment, use the Internet, access data on a USB stick, print on pre-configured printers etc. — but not be able to change anything permanently besides files in the home directory.

Questions:

Do we need any further roles? We considered a poweruser but had problems to define how this is different from the "normal user"

Besides creating a default setup, we have to consider other uses like:

high security lockdown, e.g. in a government usage
relaxed settings — the extreme where the root password is never required
an admin that wants to change some settings

So, while we define a default and make changes to the system to make this possible, let's add admin changeable settings, e.g. via polkit and thus not make the above cases impossible.

It would be great to have a graphical front end to change these values.

Authentication via polkit

polkit offers the following choices to authenticate users for a task:

via the root password
via their own password
no authentication needed
reject

Communication

Please discuss on the opensuse-factory mailing list.

This document is based on discussions between the following persons:

Changes/addons in the sections regarding "Printer" and "Scanner" have been made by:

Johannes Meixner