Supplementary groups #6908

alexey-tikhonov · 2023-08-30T20:44:23Z

No description provided.

src/sbus/connection/sbus_connection.c

src/responder/common/responder_common.c

src/sbus/connection/sbus_connection.c

src/util/become_user.c

src/sbus/connection/sbus_connection.c

src/util/become_user.c

src/sbus/connection/sbus_connection.c

src/util/become_user.c

src/sbus/connection/sbus_connection.c

src/util/become_user.c

src/sbus/connection/sbus_connection.c

src/util/become_user.c

src/util/usertools.c

src/sbus/connection/sbus_connection.c

src/util/become_user.c

src/sbus/connection/sbus_connection.c

src/util/become_user.c

It will be used by 'monitor' to first read 'sssd.conf' then switch uid/gid before writing 'config.ldb' This is required in case sssd.service::User and sssd.conf::user do not match.

It's already read in `get_monitor_config()`

`sss_ini_get_string_config_value()` is a wrapper around `ini_get_string_config_value()`, whose docs says ``` Returned value needs to be freed after use. ``` But an attempt to free 'const char *' results in discarded-qualifiers warning.

- perform_checks(): log actual owner - sss_confdb_create_ldif(): use SSSDBG_TRACE_LDB

552390a mentioned ``` might be useful e.g. in RPM %post scripts. ``` but it didn't happen. SSSD performs cache upgrade at startup automatically, explicit command doesn't have any use. On the other hand, it can spoil cache files ownership if users used to run 'sssctl' and SSSD do not match. :relnote: sssct `cache-upgrade` command was removed. SSSD performs automatic upgrade at startup when needed.

There are some known issues like SSSD#5536 but those have to be solved differently. Having 'CAP_KILL' in sssd.service doesn't help anyway (and currently isn't used anyhow).

(1) read sssd.conf (should be readable by user that is used to start monitor) (2) switch user to sssd.conf::user (if configured), drop all capabilities (3) write config.ldb This ensures all SSSD components can read config.ldb without capabilities even if (deprecated) sssd.conf::user is used.

:relnote: *IMPORTANT note for downstream maintainers!* This release features significant improvements of "running with less privileges (under unprivileged service user)" feature. There is still a ./configure option '--with-sssd-user=' available that allows downstream package maintainers to choose if support of non-root service user should be built. In case such support is built, a preferred way to configure service user is simply by starting SSSD under this user; for example, using 'User=/Group=' options of systemd sssd.service file. Upstream defaults are to build "--with-sssd-user=sssd" and to install systemd service with "User=/Group=sssd'. In this case, only several helper processes - 'ldap_child', 'krb5_child' and 'selinux_child' - are executed with elevated capabilities (that are now granted using fine grained file capabilities instead of SUID bit). All other SSSD components run without any capabilities. In this scenario it's still possible to re-configure SSSD to run under 'root' (if needed for some reason): besides changing "User/Group=" options, some other tweaks of systemd service files are required. Those tweaks are described in the comments in service files. If SSSD is built "--with-sssd-user=sssd" but configured to run under "root", it's still possible to use a legacy sssd.conf::user option to change a service user at startup. This requires granting CAP_SET_UID/ CAP_SET_GID capabilities to sssd.service (again, read comments in the service file). There should be no reason to prefer sssd.conf::user option over sssd.service::User option, barring very exotics setups where it's impossible to configure initial service user. Take a note, that this release deprecates sssd.conf::user and it's support might be removed in future releases. Further, doesn't matter if SSSD is built "--with-sssd-user=sssd" or "--with-sssd-user=root", when it's configured to run under "root" (in both cases) it still runs without capabilities, the same way as when it's configured to run under "sssd" user. The only difference is from DAC perspective. Important: owner of /etc/sssd/sssd.conf file (and snippets) should match user configured to start SSSD service. Upstream spec file changes ownership of existing sssd.conf to 'sssd' during package installation for seamless upgrades. Additionally, this release fixes a large number of issues with "socket activation of responder" feature, making it operable out-of-the-box when the package is built "--with-sssd-user=sssd". Please take a note, that user configured to run main sssd.service and socket activated responders (if used) should match (i.e. if sssd.service is re-configured from upstream defaults to 'root' then responders services also should be re-configured). Downstream package maintainers are advised to carefully inspect changes in contrib/sssd.spec.in, src/sysv/systemd/* and ./configure options that this release brings!

Since now SSSD starts and runs under %{sssd_user} by default, make sure cache files left from previous version are %{sssd_user}:%{sssd_user} owned.

Since now SSSD starts and runs under %{sssd_user} by default, make sure config files left from previous version are %{sssd_user}:%{sssd_user} owned.

'sssd_kcm' doesn't need CAP CHOWN/SET-ID itself but needs to have it in bounding set so that 'krb5_child' run by 'sssd_kcm' can get those capabilities. CAP_DAC_OVERRIDE is used to access sssd.conf and log folder. The latter can be dropped once (if) 'sssd_kcm' is changed to run under 'sssd' user by default. An approach to use 'SupplementaryGroups=' isn't practical here because config files aren't readable by group and changing this in existing setups might be cumbersome. It should be easier to make 'sssd_kcm' to run under 'sssd' user.

User used to run 'sssctl', 'sssd_kcm', etc (typically root) might not match user configured to run SSSD service.

See https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#PIDFile= ``` Note that PID files should be avoided in modern projects. Use Type=notify, Type=notify-reload or Type=simple where possible, which does not require use of PID files to determine the main process of a service and avoids needless forking. ``` SSSD uses "Type=notify"

instead of /var/run. SSSD run under non-privileged user can't write to /var/run. Anyway this file is for internal use only, systemd doesn't need it.

This will also allow to use "SecureBits=noroot" in sssd.service

in sssd.service to avoid processes gaining all capabilities from bounding set during execv() with uid=0/gid=0 (so that, for example, 'sssd_be' runs without capabilities even if "User=root")

so that SSSD built --with-sssd-user=sssd but run under 'root' can get to sssd.conf without capabilities (using "SupplementaryGroups=sssd") sssd.conf still needs to be chown'ed to 'root:root' manually in this case.

For a real device this is handled by udev rule that makes device readable by SSSD. This rule doesn't work with mocked device.

alexey-tikhonov · 2024-02-15T12:32:49Z

Superseded by #7193

github-actions bot reviewed Aug 30, 2023

View reviewed changes