Skip to content

Instantly share code, notes, and snippets.

@ok-ryoko

ok-ryoko/f39-workstation-suid-root-binaries.md

Last active February 12, 2024 17:51
Show Gist options
  • Save ok-ryoko/df15bfb7b3032f3f093f0865f3efb39b to your computer and use it in GitHub Desktop.
Save ok-ryoko/df15bfb7b3032f3f093f0865f3efb39b to your computer and use it in GitHub Desktop.
Download ZIP
SUID-root Binaries in Fedora Workstation 39
Raw
f39-workstation-suid-root-binaries.md

SUID-root Binaries in Fedora Workstation 39

by OK Ryoko, revision 2024-02-12.1

Assumed audience: Linux system administrators, Linux utility authors and Fedora Linux package maintainers. Familiarity with process credentials, capabilities, syscalls, strace, Linux PAM and SELinux is assumed.

In this report, I build on the work described in SUID-root Binaries in Fedora Workstation 38. I focus on identifying the file capabilities needed to limit the level of privilege attainable by the new SUID-root binaries in Fedora Workstation 39.

I provide a high-level summary of outcomes in the “The findings at a glance” section.

Appendix A expands the abbreviations that appear in this report.

Appendix B presents metadata for the SUID-root binaries not covered in the main text.

Table of contents

Characterization of environments

Installed to a virtual hard disk drive

My findings are for an installation of Fedora Workstation 39 1.5, virtualized using the libvirt 9.0.0 API with the QEMU/KVM driver from the image obtained via the following torrent:

https://torrent.fedoraproject.org/torrents/Fedora-Workstation-Live-x86_64-39.torrent

This image had SHA256 checksum af52046e43c6f06afd3456d2a9a36dd9782fcb204f05a21b1c31f593db36a8e8.

When creating the virtual machine, I added a virtiofs shared file system so that I could extract traces and logs easily.

Here’s some basic system information:

user@fedora:~$ uname -a # a: all
Linux fedora 6.5.6-300.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct  6 19:57:21 UTC 2023 x86_64 GNU/Linux

SELinux is enabled and enforcing:

user@fedora:~$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33

The selinux-policy-targeted-38.28-1.fc39.noarch package provides the loaded policy.

On the first boot of the new system, I created a single unprivileged and unconfined user who was configured automatically:

user@fedora:~$ id
uid=1000(user) gid=1000(user) groups=1000(user),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

By default, the Anaconda installer locks the root account:

user@fedora:~$ sudo passwd -S root # S: status
root LK 1969-12-30 0 99999 7 -1 (Password locked.)

My shell had a full bounding capability set but no other capabilities:

user@fedora:~$ cat /proc/$$/status | grep '^Cap'
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000

No securebits base or locked flags had been set.

I didn’t upgrade any packages on the system explicitly after the installation procedure.

I installed the following packages from the fedora repository to gain access to utilities for my analyses:

My first time using dnf(8) to install packages, I was asked whether to import the following GPG key:

Importing GPG key 0x18B8E74C:
 Userid     : "Fedora (39) <fedora-39-primary@fedoraproject.org>"
 Fingerprint: E8F2 3996 F232 1864 0CB4 4CBE 75CF 5AC4 18B8 E74C
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-39-x86_64
Is this ok [y/N]:

I gave my assent after comparing the fingerprint to the value listed on https://fedoraproject.org/security/ for equality.

Finally, I disabled automatic software updates in GNOME Software to preserve the environment.

Live in memory

I examined the userhelper(8) program in the live environment, which differs from the system installed to a disk as follows:

  • the host name is localhost-live;
  • the user name is liveuser, and
  • the root account is unlocked and has an empty password.

Conventions for presenting results

I obfuscated timestamps because they were irrelevant to the analyses.

I omitted all sudo(8) password prompts for brevity.

I normalized all hard tabs to spaces in command output.

I always had strace(1) write output to a file using the --output option, which I omitted from reported commands because it doesn’t change the content of the trace.

Likewise, I always redirected the output of tail(1)–grep(1) pipelines to a file.

Prompts for commands come in two flavors: [user@fedora ~]$ means I’m in a login shell and user@fedora:~$ means I’m in a nonlogin shell.

The SUID-root binaries in detail

In a virtual console (tty2), I searched the root file system for SUID-root binaries using find(1):

[user@fedora ~]$ sudo find / -ignore_readdir_race -perm /u=s -user root
/usr/bin/chage
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/fusermount
/usr/bin/fusermount-glusterfs
/usr/bin/fusermount3
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/pkexec
/usr/bin/su
/usr/bin/sudo
/usr/bin/umount
/usr/bin/vmware-user-suid-wrapper
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/libexec/dbus-1/dbus-daemon-launch-helper
/usr/libexec/openssh/ssh-keysign
/usr/libexec/spice-gtk-x86_64/spice-client-glib-usb-acl-helper
/usr/libexec/Xorg.wrap
/usr/libexec/libgtop_server2
/usr/libexec/qemu-bridge-helper
/usr/sbin/grub2-set-bootflag
/usr/sbin/mount.nfs
/usr/sbin/pam_timestamp_check
/usr/sbin/unix_chkpwd
/usr/sbin/userhelper

Of these 27 results, 2 binaries had not been present on an installation of Fedora Workstation 38 1.6:

/usr/bin/chfn
/usr/bin/chsh

Unless stated otherwise, all these binaries have owner root, group root and mode -rwsr-xr-x with no extended attributes other than security.selinux.

I first discuss how changes to the binaries I had already investigated impact the reference use cases in SUID-root Binaries in Fedora Server 38 and SUID-root Binaries in Fedora Workstation 38. I then examine the two new SUID-root binaries, /usr/bin/chfn and /usr/bin/chsh, in detail. These binaries had previously been provided by the util-linux-user package and are now provided by the util-linux package.

I defer mention of binaries that haven’t changed significantly since Fedora Workstation 38 with respect to my reference use cases to Appendix B.

/usr/bin/mount

Overview

  • Program to mount file systems
  • Provided by util-linux-core-2.39.2-1.fc39.x86_64
  • Has SHA256 checksum a709f0807a33e526058f52f914793aa1bb4cff472592bd2fb9cba55248980534
  • Has security context system_u:object_r:mount_exec_t:s0 set by the mount 1.16.1 module

How has this binary changed since Fedora Workstation 38 1.6?

The corresponding procedures outlined in SUID-root Binaries in Fedora Server 38 and SUID-root Binaries in Fedora Workstation 38 are reproducible in Fedora Workstation 39.

libmount(3) now uses the new mount API introduced in Linux 5.2. On Fedora Workstation 39, mount(8) traces will therefore contain calls to, e.g., fsconfig(2), fsmount(2) and move_mount(2), rather than mount(2):

1984<mount> fsconfig(3<anon_inode:[fscontext]>, FSCONFIG_SET_STRING, "source", "/dev/vda1", 0) = 0
1984<mount> fsconfig(3<anon_inode:[fscontext]>, FSCONFIG_CMD_CREATE, NULL, NULL, 0) = 0
1984<mount> fsmount(3<anon_inode:[fscontext]>, FSMOUNT_CLOEXEC, 0) = 4</>
1984<mount> statx(4</>, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_MNT_ID, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=STATX_ATTR_MOUNT_ROOT, stx_mode=S_IFDIR|0755, stx_size=6, ...}) = 0
1984<mount> mount_setattr(4</>, "", AT_EMPTY_PATH, {attr_set=MOUNT_ATTR_NOSUID|MOUNT_ATTR_NODEV, attr_clr=0, propagation=0 /* MS_??? */, userns_fd=0}, 32) = 0</dev/pts/0>
1984<mount> move_mount(4</>, "", AT_FDCWD</home/user>, "/mnt/upart", MOVE_MOUNT_F_EMPTY_PATH) = 0

Source: sudo strace -u user -fyY mount /mnt/upart, where -u is short for --user and -fyY for --follow-forks --decode-fds=path --decode-pids=comm

/usr/bin/umount

Overview

  • Program to unmount file systems
  • Provided by util-linux-core-2.39.2-1.fc39.x86_64
  • Has SHA256 checksum c461753b7aff56db84a39dbbbe923f607d55f70dc8357b46f02a8e2c073ff0e0
  • Has security context system_u:object_r:mount_exec_t:s0 set by the mount 1.16.1 module

Can the findings for /usr/bin/mount be generalized to this binary?

Yes. mount(8) and umount(8) have matching implementations and a shared dependence on libmount(3).

/usr/sbin/pam_timestamp_check

Overview

  • Program to validate or remove the default timestamp (for cached authentication results)
  • Provided by pam-1.5.3-2.fc39.x86_64
  • Has SHA256 checksum 42660967c8ee116c1ea0c582eee450193ee2f858af50f59bccfea23ae57f4318
  • Has security context system_u:object_r:pam_timestamp_exec_t:s0 set by the authlogin 2.5.1 module

How has this binary changed since Fedora Workstation 38 1.6?

The corresponding procedure outlined in SUID-root Binaries in Fedora Server 38 is reproducible in Fedora Workstation 39.

sudo(8) now uses a pseudoterminal by default (see commit 894daa8), so it’s no longer possible to obtain accurate traces of pam_timestamp_check(8) using strace(1). This is because, under sudo(8), pam_timestamp_check(8) will manipulate the authentication timestamps for the pseudoterminal. To obtain accurate traces, it’s therefore necessary to disable this feature temporarily like so:

user@fedora:~$ sudo visudo /etc/sudoers.d/no_pty
Defaults !use_pty

sudo(8) will now run without creating a pseudoterminal for the given command.

When done tracing, delete the custom policy:

user@fedora:~$ sudo rm /etc/sudoers.d/no_pty

/usr/bin/sudo

  • Program to execute a command as another user or group in a configurable manner
  • Provided by sudo-1.9.14-1.p3.fc39.x86_64
  • Installed with mode ---s--x--x
  • Has SHA256 checksum a9ddaec6f174559759cd416bfcb0b94b9947427ea80fc26d5fb77cb79a15f617
  • Has security context system_u:object_r:sudo_exec_t:s0 set by the sudo 1.10.0 module

How has this binary changed since Fedora Workstation 38 1.6?

The corresponding procedure outlined in SUID-root Binaries in Fedora Server 38 is reproducible in Fedora Workstation 39.

sudo(8) no longer zeros the hard limit on the core dump file size and therefore no longer needs CAP_SYS_RESOURCE (see commit b1deffb).

/usr/sbin/userhelper

Overview

  • Program to help other programs interface with PAM
  • Provided by usermode-1.114-8.fc39.x86_64
  • Installed with mode -rws--x--x
  • Has SHA256 checksum 9a28e9bd86cf949d8596f169cc61a6858df777a337ae6111be63e6594ae98a82
  • Has security context system_u:object_r:userhelper_exec_t:s0 set by the userhelper 1.8.1 module

How has this binary changed since Fedora Workstation 38 1.6?

This program no longer supports the Anaconda installer:

liveuser@localhost-live:~$ cat /usr/share/applications/anaconda.desktop | grep '^Exec'
Exec=liveinst

liveuser@localhost-live:~$ command -v liveinst
/usr/bin/liveinst

liveuser@localhost-live:~$ file /usr/bin/liveinst
/usr/bin/liveinst: Bourne-Again shell script, ASCII text executable

The file at /usr/bin/liveinst is the same shell script that consolehelper(8) and userhelper(8) conspired to run at /usr/sbin/liveinst in Fedora Workstation 38.

How does Anaconda run with privileges without userhelper(8)? The liveinst script now uses pkexec(1), another SUID-root binary I covered in SUID-root Binaries in Fedora Server 38, to rerun itself as root:

2831<liveinst> execve("/usr/bin/pkexec", ["pkexec", "/usr/bin/liveinst"], 0x55aa520eccb0 /* 26 vars */) = 0

Source: sudo strace -u liveuser -fyY -E DBUS_SESSION_BUS_ADDRESS="${DBUS_SESSION_BUS_ADDRESS}" gtk-launch anaconda, where -E is short for --env

/usr/bin/chfn

Overview

  • Program to change a user’s finger information, i.e., the GECOS field in /etc/passwd
  • Provided by util-linux-2.39.2-1.fc39.x86_64
  • Installed with mode -rws--x--x
  • Has SHA256 checksum 79f263d701c75adb7a707353b0f236fd67a5bee62150f8fe74337ff9e90767ae
  • Has security context system_u:object_r:chfn_exec_t:s0 set by the usermanage 1.19.0 module

Why does this binary need to be SUID-root?

chfn(1) must be able to update /etc/passwd. This involves creating a temporary file at /etc/.chfn.XXXXXX (CAP_DAC_OVERRIDE), changing the owner and group of that file (CAP_CHOWN) and changing the mode of that file (CAP_FOWNER).1 chfn(1) must also be able to run the following PAM stack:

#%PAM-1.0
auth       sufficient   pam_rootok.so
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    include      system-auth

Source: cat /etc/pam.d/chfn

Therefore, chfn(1) should also be able to write to the audit log (CAP_AUDIT_WRITE).

Can we replace the SUID bit with zero or more file capabilities?

By default, chfn(1) is restricted from changing the finger information by the configuration in /etc/login.defs. I therefore updated /etc/login.defs like so:

[user@fedora ~]$ sudo sed -i -e 's/^#CHFN_RESTRICT.*/CHFN_RESTRICT fr/' /etc/login.defs # i: in-place, e: expression

This change would allow me to set the full name and office room number.

Next, I retrieved the current GECOS field:

[user@fedora ~]$ cat /etc/passwd | grep '^user' | cut -d ':' -f 5 # d: delimiter, f: fields
Fedora User

I then tried setting the office room number to the current Fedora Linux release number:

[user@fedora ~]$ chfn -o 39 user # o: office
Changing finger information for user.
Password:

Finger information changed.

[user@fedora ~]$ cat /etc/passwd | grep '^user' | cut -d ':' -f 5
Fedora User,39

I successfully reproduced this step after making the following modifications:

[user@fedora ~]$ sudo chmod u-s /usr/bin/chfn
[user@fedora ~]$ sudo setcap cap_chown,cap_dac_override,cap_fowner,cap_audit_write=ep /usr/bin/chfn

The audit log showed three successes and zero failures:

type=USER_AUTH msg=audit(0.0:228): pid=2000 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_usertype,pam_localuser,pam_unix acct="user" exe="/usr/bin/chfn" hostname=fedora addr=? terminal=tty2 res=success'UID="user" AUID="user"
type=USER_ACCT msg=audit(0.0:229): pid=2000 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="user" exe="/usr/bin/chfn" hostname=fedora addr=? terminal=tty2 res=success'UID="user" AUID="user"
type=CRED_ACQ msg=audit(0.0:230): pid=2000 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_localuser,pam_unix acct="user" exe="/usr/bin/chfn" hostname=fedora addr=? terminal=tty2 res=success'UID="user" AUID="user"

Source: sudo tail -n 64 /var/log/audit/audit.log | grep 'chfn', where -n is short for --lines, after omitting messages for the SUID-root run of chfn(1)

As a confidence check, I tried (unsuccessfully) to set a field I shouldn’t be able to set…

[user@fedora ~]$ chfn -p '(888) 555-0181' user # p: office-phone
chfn: login.defs forbids setting Office Phone

… as well as change the finger information of another user:

[user@fedora ~]$ sudo useradd noriko
[user@fedora ~]$ chfn -f 'Noriko Takaya' noriko # f: full-name
chfn: running UID doesn't match UID of user we're altering, change denied: Permission denied

Does this program drop privileges? If so, when?

As far as I can tell from the source code and strace(1) output, chfn(1) doesn’t drop privileges explicitly by calling any of setuid(2), seteuid(2), setreuid(2) or setresuid(2).

What role does SELinux play in constraining the privilege of the program?

There are no transitions from the unconfined_t domain through the chfn_exec_t file type:

[user@fedora ~]$ sudo sesearch -T -s unconfined_t -t chfn_exec_t # T: type_trans, s: source, t: target
[user@fedora ~]$

Thus, chfn(1) runs unconfined.

Comments

If unprivileged users should not be able to change their finger information, then consider unsetting the SUID bit on /usr/bin/chfn.

Source code references

All line numbers refer to points in source code after applying the patches in src.fedoraproject.org/rpms/util-linux@59309f2.

The HAVE_MKOSTEMP and HAVE_LIBUSER macros are assumed to be defined and undefined, respectively.

1 In util-linux/login-utils/chfn.c@v2.39.2, main calls setpwnam, passing ".chfn" for the prefix argument (line 384). In util-linux/login-utils/setpwnam.c@v2.39.2, setpwnam calls xfmkstemp to create the temporary file at /etc/.chfn.XXXXXX (line 87), then fchown(2) on that file (line 91) and then fchmod(2) on that file (line 143). Finally, setpwnam renames /etc/.chfn.XXXXXX via rename(2), passing PASSWD_FILE as the new path (line 163). In util-linux/login-utils/setpwnam.h@v2.39.2, PASSWD_FILE is a macro defined as the _PATH_PASSWD macro (line 20) that, according to line 60 of util-linux/include/pathnames.h@v2.39.2, expands to "/etc/passwd". In util-linux/include/fileutils.h@v2.39.2, xfmkstemp wraps xmkstemp (line 25). In util-linux/lib/fileutils.c@v2.39.2, xmkstemp wraps mkstemp_cloexec (line 70), which wraps mkostemp(3) (line 24).

/usr/bin/chsh

Overview

  • Program to change a user’s login shell
  • Provided by util-linux-2.39.2-1.fc39.x86_64
  • Installed with mode -rws--x--x
  • Has SHA256 checksum 17a452909206b56469c58242b98fe6d49e9f41752ece0d63ead3bcc64882e5c6
  • Has security context system_u:object_r:chfn_exec_t:s0 set by the usermanage 1.19.0 module

Can we generalize the findings for /usr/bin/chfn to this binary?

Yes. chfn(1) and chsh(1) both create a temporary file with which to update /etc/passwd using the same mechanism,1 and both run an identical PAM stack. I was able to change my login shell after making the same modifications as I did to /usr/bin/chfn:

[user@fedora ~]$ cat /etc/passwd | grep '^user' | cut -d ':' -f 7
/bin/bash

[user@fedora ~]$ sudo chmod u-s /usr/bin/chsh
[user@fedora ~]$ sudo setcap cap_chown,cap_dac_override,cap_fowner,cap_audit_write=ep /usr/bin/chsh
[user@fedora ~]$ chsh -s /bin/sh user
Changing shell for user.
Password:
Shell changed.

[user@fedora ~]$ cat /etc/passwd | grep '^user' | cut -d ':' -f 7
/bin/sh

As a confidence check, I tried (unsuccessfully) to change the login shell of the user I created while investigating /usr/bin/chfn:

[user@fedora ~]$ chsh -s /bin/sh noriko
chsh: running UID doesn't match UID of user we're altering, shell change denied: Permission denied

Comments

If unprivileged users should not be able to change their login shell, then consider unsetting the SUID bit on /usr/bin/chsh.

Source code references

The HAVE_LIBUSER macro is assumed to be undefined.

1 In util-linux/login-utils/chsh.c@v2.39.2, main calls setpwnam, passing ".chsh" for the prefix argument (line 297). setpwnam is described in more detail in the corresponding citation for /usr/bin/chfn.

The findings at a glance

I identified 27 SUID-root binaries on an installation of Fedora Workstation 39 to a VirtIO disk.

In SUID-root Binaries in Fedora Server 38 and SUID-root Binaries in Fedora Workstation 38, I had already analyzed 25 of these binaries.

Of these, 2 needed fewer capabilities to enable the reference use cases:

  • /usr/bin/sudo
  • /usr/sbin/userhelper

I was able to substitute the SUID bit using file capabilities on all the new binaries:

  • /usr/bin/chfn
  • /usr/bin/chsh

The new programs of interest ran unconfined by SELinux.

To get a high-level idea of the privileges needed by the SUID-root binaries that come with Fedora Workstation 39, I tallied the file capabilities that I ended up setting to enable the reference use cases:

          CAP_CHOWN ┤██████████ 6
   CAP_DAC_OVERRIDE ┤██████████████ 7
CAP_DAC_READ_SEARCH ┤████████ 4
         CAP_FOWNER ┤████████ 4
         CAP_SETGID ┤██████████████ 7
         CAP_SETUID ┤██████████████ 7
      CAP_NET_ADMIN ┤██ 1
      CAP_SYS_ADMIN ┤████████████ 6
   CAP_SYS_RESOURCE ┤ 0
    CAP_AUDIT_WRITE ┤██████████████████████ 11

Supporting information

Appendix A: List of abbreviations

API Application programming interface

CC Creative Commons

FUSE Filesystem in Userspace

GECOS General Comprehensive Operating System

GID Group ID

GNU GNU’s Not Unix

GPG GNU Privacy Guard

GRUB Grand Unified Bootloader

ID Identifier

KVM Kernel-based Virtual Machine

NFS Network File System

PAM Pluggable Authentication Modules

QEMU Quick Emulator

SELinux Security-Enhanced Linux

SHA Secure Hash Algorithm

SPICE Simple Protocol for Independent Computing Environments

SSH Secure Shell

SUID Set-UID

UID User ID

USB Universal Serial Bus

VM Virtual machine

Appendix B: Metadata for the remaining binaries

/usr/bin/chage

  • Program to display and change user password expiry information
  • Provided by shadow-utils-2:4.14.0-1.fc39.x86_64
  • Has SHA256 checksum a3173997e1b202950a54860cde97530ab2db135b1ba828beb33a4d95cb112774
  • Has security context system_u:object_r:passwd_exec_t:s0 set by the usermanage 1.19.0 module

/usr/bin/fusermount

  • Program to mount and unmount FUSE v2 file systems
  • Provided by fuse-2.9.9-17.fc39.x86_64
  • Has SHA256 checksum 1016a98425a6289e63e24d0670cc63f656054b7f1d80bcb172a408d4cbc85402
  • Has security context system_u:object_r:fusermount_exec_t:s0 set by the mount 1.16.1 module

/usr/bin/fusermount-glusterfs

  • Program to mount and unmount Gluster file systems
  • Provided by glusterfs-fuse-11.0-5.fc39.x86_64
  • Has SHA256 checksum 632efb9ed73871ab16c511c7a610ca268689a1d47833d355b81cfa8114131b72
  • Has security context system_u:object_r:bin_t:s0

/usr/bin/fusermount3

  • Program to mount and unmount FUSE v3 file systems
  • Provided by fuse3-3.16.1-1.fc39.x86_64
  • Has SHA256 checksum 904a8f9637c6998ed285cd8289fe267b07d215e44caec5115d03bb2254506dbe
  • Has security context system_u:object_r:fusermount_exec_t:s0 set by the mount 1.16.1 module

/usr/bin/gpasswd

  • Program to administer user groups
  • Provided by shadow-utils-2:4.14.0-1.fc39.x86_64
  • Has SHA256 checksum fa320ced9d199d45bb6f88c15a5c80d38de531c208db3ddf2730fd33686c5735
  • Has security context system_u:object_r:groupadd_exec_t:s0 set by the usermanage 1.19.0 module

/usr/bin/newgrp

  • Program to change the GIDs during a login session
  • Provided by shadow-utils-2:4.14.0-1.fc39.x86_64
  • Has SHA256 checksum 0758c5d07299fcf52d7d907350b91c02fd9db92e85db578029311379209348dc
  • Has security context system_u:object_r:bin_t:s0

/usr/bin/passwd

  • Program to update authentication tokens using PAM
  • Provided by passwd-0.80-15.fc39.x86_64
  • Has SHA256 checksum 9f369ef1b405aca3a0b7a8b7badc53c53bc73730368bc2e9134ffb4b6262c281
  • Has security context system_u:object_r:passwd_exec_t:s0 set by the usermanage 1.19.0 module

/usr/bin/pkexec

  • Program to execute a command as another user following authorization by Polkit
  • Provided by polkit-123-1.fc39.x86_64
  • Has SHA256 checksum f1b4b019b8f1cbc28d5c204cab20356a82e7b890c3b536f121a3332278834135
  • Has security context system_u:object_r:bin_t:s0

/usr/bin/su

  • Program to run a new shell or a command within a new shell as another user or group
  • Provided by util-linux-2.39.2-1.fc39.x86_64
  • Has SHA256 checksum e1073223ad40d277ad2717b4d60b556d30403e07e51eb4389a9858abd97eaeb9
  • Has security context system_u:object_r:su_exec_t:s0 set by the su 1.12.0 module

/usr/bin/vmware-user-suid-wrapper

/usr/lib/polkit-1/polkit-agent-helper-1

  • Polkit agent helper to re-authenticate a user
  • Provided by polkit-123-1.fc39.x86_64
  • Has SHA256 checksum 73f2e3da9c59c1dcb43ea4f1e139bf241c2482347e216f04cba74dcbdff87f92
  • Has security context system_u:object_r:policykit_auth_exec_t:s0 set by the policykit 1.3.0 module

/usr/libexec/dbus-1/dbus-daemon-launch-helper

  • Program to help dbus-daemon(1) start a D-Bus service on demand as another user
  • Provided by dbus-daemon-1:1.14.10-1.fc39.x86_64
  • Installed with group dbus and mode -rwsr-x---
  • Has SHA256 checksum 6f580a72653cad5d73511c6a5d5f67cefdda336c6533f13c5d2dbafc6d998511
  • Has security context system_u:object_r:dbusd_exec_t:s0 set by the dbus 1.19.0 module

/usr/libexec/openssh/ssh-keysign

  • OpenSSH helper for host-based authentication
  • Provided by openssh-9.3p1-9.fc39.x86_64
  • Installed with mode -r-sr-xr-x
  • Has SHA256 checksum f48922594a181ffcaec1b6253a9cc5dfd5d36c1f366c7c4fc5f2bb8f76c882bb
  • Has security context system_u:object_r:ssh_keysign_exec_t:s0 set by the ssh 2.4.2 module

/usr/libexec/spice-gtk-x86_64/spice-client-glib-usb-acl-helper

/usr/libexec/Xorg.wrap

/usr/libexec/libgtop_server2

  • Program to collect system monitoring data, e.g., resource usage
  • Provided by libgtop2-2.41.1-2.fc39.x86_64
  • Has SHA256 checksum 3ee6dd4e2a6389e5af140df8cdfe9d9c77b82fdab36b4674ac0bed875d3022be
  • Has security context system_u:object_r:bin_t:s0

/usr/libexec/qemu-bridge-helper

  • QEMU helper to let unprivileged users connect a QEMU VM to a bridged network interface
  • Provided by qemu-common-2:8.1.0-1.fc39.x86_64
  • Has SHA256 checksum a91eff46f1264c97661777c82aeb7e701a509c0d6fb1c2256dbd5d2c0d941456
  • Has security context system_u:object_r:virt_bridgehelper_exec_t:s0 set by the virt 1.5.0 module

/usr/sbin/grub2-set-bootflag

  • Program to set a bootflag in the GRUB environment block
  • Provided by grub2-tools-minimal-1:2.06-100.fc39.x86_64
  • Has SHA256 checksum dfa34c39cc4b3e8c0cb88fdca5f037db878ed72ea5df2f4e81eb4dfb7b708b1f
  • Has security context system_u:object_r:bootloader_exec_t:s0 set by the bootloader 1.14.0 module

/usr/sbin/mount.nfs

  • Program to mount NFS file systems
  • Provided by nfs-utils-1:2.6.3-1.rc3.fc39.x86_64
  • Has SHA256 checksum 097c142c5b718dfc7e4ff0daf1842ec591535dc6f064fa774cbf16d349e97ab7
  • Has security context system_u:object_r:mount_exec_t:s0 set by the mount 1.16.1 module

/usr/sbin/unix_chkpwd

  • Helper for the pam_unix PAM module that verifies the running user’s password
  • Provided by pam-1.5.3-2.fc39.x86_64
  • Has SHA256 checksum b78d6c1b0c0aaa0f720922445a4f6f66db8d0ed44f73890c8c31e2ebb8806ece
  • Has security context system_u:object_r:chkpwd_exec_t:s0 set by the authlogin 2.5.1 module

Feedback and support

Please connect with me if you have constructive comments about this article, especially if you have a use case I didn’t cover or are unable to reproduce a procedure in an identical environment.

I will maintain this article until Fedora Linux 39 reaches end of life on November 12, 2024.

Funding sources

The author acknowledges private funding by one anonymous sponsor.

Licensing

All original copyrightable content in this document is marked with CC0 1.0 Universal.

Revision history

2024-02-12.1

Revise executive statement

2024-02-11.1

Initial revision

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment