Security issue on Linux Workstation with multiple accounts: cross-account artifact creation

[PavelSosin-320]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Podman randomly creates BTRFS subvolumes representing OCI artifacts on the Fedora 34 workstation with multiple accounts when accounts are frequently switched. Accounts that were never used for running Podman get btrfs subvolumes when another account creates/runs containers.
Steps to reproduce the issue:

1. Install Fedora 34 workstation
2. Create several user accounts using standard Settings->users->create GUI application
3. Pull images and create/run containers
4. Switch user using GNOME "switch user" menu (in the upper right corner of the desktop)
5. Open Terminal application
6. Check content of ~/.local/user/share/containers/storage
7. Run systemctl --user daemon-reexec
8. Check ~/.local/user/share
   Describe the results you received:
   Podman info returns
   ERRO[0000] stat /home/<old user ..... storage.conf" : permission denied butI found unexpected content in the "Podman storage"

Describe the results you expected:
It must be empty if account's owner never used Podman

Additional information you deem important (e.g. issue happens only occasionally):
Happens occasionally
Output of podman version:

Version:  3.4.1

Output of podman info --debug:

Depends on user

Package info (e.g. output of rpm -q podman or apt list podman):

podman-3.4.1-1 fc34.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)
Yes/No

Additional environment details (AWS, VirtualBox, physical, etc.):
I found that unlike USER environment variable, HOME environment variable doesn't follow immediately after user's switch. I saw somewhere in the systemd documentation that it is the normal systemd behavior. When GNOME Terminal is invoked it inherits the current value.
The GNOME GUI session is managed by systemd - HOME may be not 100% synchronized.
Systemd itself demands to keep Unit's environment block as slim as possible for every unit including systemd-user-session that fills initial systemd manager environment.
Systemd itself never uses environment variables for the service configuration providing % placeholders instead. For the "private" configuration conf files in the .d directories and merged with the "default" configuration are used - they are static and independent from the dynamically built environment blocks.
User-specific configurations can be generated from template. This is systemd mechanism that drives Workstation.

[PavelSosin-320]

And the reason is in the systemd: there is long discussion but it looks like XDG_CONFIG_HOME, XDG_DATA_HOME, etc. are not set automatically, at least at the beginning of user's GUI session startup by systemd. It is not set synchronously. The user's systemd configuration lacks of targets, except the default. I hope that everything that needs complete configuration presence can wait for systemd-pamd or systemd-homed service but see RedHatBugsilla - Homed issue..
Otherwise, everything needed has to be put into environment configuration file
GUI-less session starts much faster - only "sourcing" .profile but "Container's" service has to wait for systemd-pam if it doesn't have its own environment block.

[rhatdan]

What change would be required to make that happen?

[PavelSosin-320]

Please, please, please ! check pam-xdg-support packaging with Podman. This package had problems in Ubuntu and fresh bugzilla record in the RedHat pam-xdg-support. After upgrade to Fedora 35 Podman stopped to work completely:
_/home/pavelsosin/.local/share/containers/storage/btrfs/subvolumes

podman container create ead53a357190 --name p1

Error: error creating container storage: error creating read-write layer with ID "c9c6e70a9ff7b767112c06faed0771559462e86b81ba60eb6a5bbb50ff52598a": stat /home/pavelsosin/.local/share/containers/storage/btrfs/subvolumes/e024d689dd363dbb6b24865e899a380420e15a8d8b78ed2e160f517528148cd2: no such file or directory
[pavelsosin@Dell ~]$ ls /home/pavelsosin/.local/share/containers/storage/btrfs/subvolumes/_
The values of XDG environment variables in the plain user session environment are incorrect, only XDG_RUNTIME_DIRECTORY is OK:
env | grep XDG
XDG_MENU_PREFIX=gnome-
XDG_SESSION_DESKTOP=gnome
XDG_SESSION_TYPE=wayland
XDG_CURRENT_DESKTOP=GNOME
XDG_SESSION_CLASS=user
XDG_RUNTIME_DIR=/run/user/1000
XDG_DATA_DIRS=/home/pavelsosin/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/

I can't find it for Fedora35

[vrothberg]

This looks like a GNOME/systemd bug to me rather than a Podman bug. Also note that "OCI artifacts" are something different (see https://github.com/opencontainers/artifacts).

[PavelSosin-320]

@vrothberg Maybe. I asked to check packaging Podman with systemd version for Fedora35. The environment of Systemd manager looks incomplete and incorrect: Some XDG variables are missed, some are not updated when I switch between users via GNOME, i.e. re-execute systemd-daemon. It is not like su - .another user. HOME and XDG variables are set into environment every systemd-user run. Some environment-related issues of pam xdg helper where reported for Ubuntu/rootless Docker too when root and non-root users are switched. After manual execution of systemctl --user daemon-reexec the environment looks inconsistent. But this is expected because daemon-reload makes environment volatile.
Yet another topic I'm testing just now: without providing the certain option for BRTFS FS mount non-root user can't remove its own subvolumes. No cleanup method works to me.

[PavelSosin-320]

Indeed, in the Workstation I can have 1 Terminal application running with several tabs connected to the different sessions of different users. su -p helps to navigate between sessions and tabs. su is out of the sync with systemd-logind! Then, I'm userid 100 but my XDG_RUNTIME_DIR is /run/user/1001/. This is exactly as in Windows.

Since sessions are controlled by systemd the User object looks more reliable:
interface org.freedesktop.login1.User {
methods:
Terminate();
Kill(in i signo);
properties:
readonly u UID = 1000;
readonly u GID = 1000;
readonly s Name = 'test';
readonly t Timestamp = 1389368964102424;
readonly t TimestampMonotonic = 36229061;
readonly s RuntimePath = '/run/user/1000';
readonly s Service = '[email protected]';
readonly s Slice = 'user-1000.slice';

[PavelSosin-320]

@vrothberg Please, help in systemd-homed - Selinux integration is needed! According to the audit log operations on the home area including read access are blocked by Selinux and corresponding entries are written into the audit.log. Usage of $HOME in the storage.conf means that all artifacts are written into the home area. The similar issue is mentioned twice: in Fedora project tests results and Podman troubleshooting The possible solution can be either moving Podman artifact storage outside of User's home area (???) or re-labeling of the Podman storage after home area mounting (???).

Is it relevant:
drwxrwxr-x. 1 pavelsosin pavelsosin system_u:object_r:unlabeled_t:s0 0 Nov 23 13:20 containers_storage
drwxrwxr-x. 1 pavelsosin pavelsosin system_u:object_r:unlabeled_t:s0 0 Nov 23 13:20 containers_storage_checkpoint
vs.
drwx------. 1 pavelsosin pavelsosin unconfined_u:object_r:gconf_home_t:s0 20 Aug 29 11:35 .local
?

[vrothberg]

Please open a dedicated issue for systemd-homed. This issue here has already so many different topics mentioned that it's hard to follow.

systemd-homed uses id-mapped mounts which I guess are causing troubles when placing a container storage on top. @giuseppe what do you think?

[giuseppe]

the idmapped mount itself should not be a problem. I guess the session is still running in the host namespace so there are no user namespaces involved?

Does it work if you run restorecon -Rv ~/?

[PavelSosin-320]

@giuseppe Unfortunately, it fails itself with multiple errors like
/home/pavelsosin/.local/share/containers/storage/btrfs/subvolumes/a20d37aac15dc7554398dbed9074c553616793f438371e8bd1f750a4f7e24e48/var/log not reset as customized by admin to system_u:object_r:container_file_t:s0:c306,c854.
Maybe, re-tag from by admin to system_u:object_r:container_file_t:s0:c306,c854 impossible regardless run as rootless user or root? pavelsosin has been created as "Admin" via Fedora setting GUI and Podman was installed on the top. What is user's role effect?
P.S. cat /etc/selinux/targeted/contexts/customizable_types
container_file_t
....
I.e. can't be re-labeled when it is in the non-static Home as I see in the SELinux tutorial . But Homed breaks this restriction. Does it mean that Podman storage can't be located on the mountable storage????

[PavelSosin-320]

I found something very similar in the CentOS forum: SELinux prevents access to the external drive. Maybe, "SELinux-man" can advise something better? If Podman storage volume is mountable btrfs volume it can be treated as "external drive".
Otherwise, rootless user can have problems in access to the created container inner files.
It may cause problems in any use-case when system drive has many partitions or computer has several drives.

[rhatdan]

Open a separate issue. This issue is way too confusing .

[PavelSosin-320]

@rhatdan really sorry for personal appeal but it looks like that something conceptually wrong in Podman running on the Fedora Workstation with GNOME 4: I expect that Podman process a child of bash that is a child of session's process that is a child of systemd ID 1 process inherits its capabilities and restrictions configured by Systemd configuration Systemd.exec conf -> Capabilities, Security. The process capabilities can and should be very restricted in the GNOME session. This is indeed very confusing, so I'm closing this issue and will open discussion instead but could some body from the Podman team can look and document how to configure systemd or create the correct drop-in configuration for Linux workstations?