Bug 1984739 - SELinux is preventing (systemd) from read, open access on the file /usr/sbin/mount.ecryptfs_private.
Summary: SELinux is preventing (systemd) from read, open access on the file /usr/sbin/...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 35
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:719d91a6f0274f43863728fb132...
: 1997457 2009954 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-07-22 05:43 UTC by Javier Fdez. Landa
Modified: 2022-06-23 08:11 UTC (History)
15 users (show)

Fixed In Version: selinux-policy-35.18-1.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-06-23 03:13:51 UTC
Type: ---


Attachments (Terms of Use)

Description Javier Fdez. Landa 2021-07-22 05:43:23 UTC
Description of problem:
After upgrading selinux-policy gnome-login can't mount ecryptfs home directory.

Workarround: Setting selinux to permisive.
SELinux is preventing (systemd) from read, open access on the file /usr/sbin/mount.ecryptfs_private.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that (systemd) should be allowed read open access on the mount.ecryptfs_private file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c '(systemd)' --raw | audit2allow -M my-systemd
# semodule -X 300 -i my-systemd.pp

Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:object_r:mount_ecryptfs_exec_t:s0
Target Objects                /usr/sbin/mount.ecryptfs_private [ file ]
Source                        (systemd)
Source Path                   (systemd)
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           ecryptfs-utils-111-22.fc34.x86_64
SELinux Policy RPM            selinux-policy-targeted-34.14-1.fc34.noarch
Local Policy RPM              selinux-policy-targeted-34.14-1.fc34.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 5.12.17-300.fc34.x86_64 #1 SMP Wed
                              Jul 14 19:39:03 UTC 2021 x86_64 x86_64
Alert Count                   7
First Seen                    2021-07-21 11:24:23 CEST
Last Seen                     2021-07-22 07:38:12 CEST
Local ID                      d81b256d-0c3c-4f10-bc56-a8250d8661a4

Raw Audit Messages
type=AVC msg=audit(1626932292.593:826): avc:  denied  { read open } for  pid=1748 comm="(systemd)" path="/usr/sbin/mount.ecryptfs_private" dev="dm-0" ino=2510137 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:mount_ecryptfs_exec_t:s0 tclass=file permissive=1


Hash: (systemd),init_t,mount_ecryptfs_exec_t,file,read,open

Version-Release number of selected component:
selinux-policy-targeted-34.14-1.fc34.noarch

Additional info:
component:      selinux-policy
reporter:       libreport-2.15.2
hashmarkername: setroubleshoot
kernel:         5.12.17-300.fc34.x86_64
type:           libreport

Potential duplicate: bug 1609474

Comment 1 Ivan Mironov 2021-07-24 19:41:22 UTC
I have the same problem. Changing selinux into "permissive" mode fixes this.

selinux-policy-34.14-1.fc34.noarch
selinux-policy-targeted-34.14-1.fc34.noarch
ecryptfs-utils-111-22.fc34.x86_64
kernel-5.13.4-200.fc34.x86_64

Comment 2 René Genz 2021-07-25 20:32:01 UTC
Mounting "~/Private" after login works in SELinux enforcing mode with `ecryptfs-mount-private`.

Changing SELinux mode for this session:
$ getenforce
$ sudo setenforce permissive

... permanently:
$ sudo nano /etc/selinux/config
change from:
SELINUX=enforcing
to:
SELINUX=permissive
$ sudo reboot

Comment 3 Kevin R. Page 2021-07-31 09:43:44 UTC
Confirmed for another F34 install here, and setting selinux to permissive as a workaround. This applies to all login modes (gdm, ssh, etc.).

To be clear: this bug prevents mounting of home directories for all users on setups using ecryptfs.

For less technical users this manifested as their systems automatically but mysteriously becoming thoroughly broken about 2 weeks ago (17 July) -- although login appears to succeed and the desktop appears, settings for firefox/thunderbird/anything aren't accessible etc. so applications don't work correctly.

selinux-policy-34.14-1.fc34.noarch
selinux-policy-targeted-34.14-1.fc34.noarch
ecryptfs-utils-111-22.fc34.x86_64
kernel-5.13.5-200.fc34.x86_64

Comment 4 René Genz 2021-08-02 14:44:01 UTC
This is how to set up eCryptfs-powered "~/Private" on Fedora 34:
## preparation
$ sudo dnf install -y ecryptfs-utils
$ sudo usermod -aG ecryptfs YOURACCOUNT
$ sudo reboot

## configuration
YOURACCOUNT$ ecryptfs-setup-private
- type your login password and press enter
- press enter to generate mount passphrase
- ~/Private and ~/.Private and ~/.ecryptfs are created
- ~/Private contains "Access-Your-Private-Data.desktop" and "README.txt" and is not writeable if not mounted
- log out

### usage
- log in with YOURACCOUNT at GDM login screen
- ~/Private should get mounted automatically and be writeable

Comment 5 René Genz 2022-03-02 07:29:35 UTC
Automatic mounting of eCryptfs "~/Private" worked on Fedora 32. Also on Fedora 34 with:
selinux-policy-34.3-1.fc34.noarch
selinux-policy-targeted-34.3-1.fc34.noarch

But does not get mounted since:
selinux-policy-34.14-1.fc34.noarch
selinux-policy-targeted-34.14-1.fc34.noarch

Problem still present with Fedora 36 (branched), hence I filed an upstream bug report: https://github.com/fedora-selinux/selinux-policy/issues/1103

Comment 6 Zdenek Pytela 2022-03-04 10:57:48 UTC
My current findings wrap-up:

F35 - selinux-policy-35.15-1.fc35.noarch ecryptfs-utils-111-24.fc35.x86_64
F36 - selinux-policy-36.4-1.fc36.noarch ecryptfs-utils-111-26.fc36.x86_64

ecryptfs-mount-private works, automounting not
neither in SELinux enforcing nor permissive

There are some rules which should be added in selinux-policy:

# cat local_crypt.cil
(allow unconfined_t mount_ecryptfs_exec_t (file (entrypoint)))
(allow mount_ecryptfs_t fs_t (filesystem (getattr)))
(allow init_t mount_ecryptfs_exec_t (file (execute open read)))
# semodule -i local_crypt.cil

After this, no AVCs are audited, but the result keeps the same.
So I don't think the only problem is in selinux-policy.

Can you help with further troubleshooting? I probably don't completely understand how it works.
I can see there is home-cryptuser-Private.mount unit.

Comment 7 René Genz 2022-03-05 00:01:55 UTC
I tested with a virtual machine with Fedora Workstation 36 installed with netinstall ISO file. Automounting works for me with the above guide, SELinux permissive mode, and these packages:
$ rpm -q selinux-policy ecryptfs-utils
selinux-policy-36.3-1.fc36.noarch
ecryptfs-utils-111-26.fc36.x86_64


To match your environment:
- I updated: $ sudo dnf install -y https://kojipkgs.fedoraproject.org//packages/selinux-policy/36.4/1.fc36/noarch/selinux-policy-36.4-1.fc36.noarch.rpm https://kojipkgs.fedoraproject.org//packages/selinux-policy/36.4/1.fc36/noarch/selinux-policy-targeted-36.4-1.fc36.noarch.rpm
- set SELinux enforcing mode
- reboot
- log in; automounting does not work
- created "local_crypt.cil" file with give content and executed `semodule -i local_crypt.cil`
- reboot
- log in; automounting works


I will help.
1. eCryptFS PAM support is required for automounting to work. Do you see "with-ecryptfs" in the following command too? Output for me is:
$ authselect current
Profile ID: sssd
Enabled features:
- with-fingerprint
- with-silent-lastlog
- with-ecryptfs
- with-mdns4

If it is missing, run `sudo authselect enable-feature with-ecryptfs` and reboot. In my working eCryptFS-Private environment I removed the feature with `sudo authselect disable-feature with-ecryptfs`, rebooted, and encountered your described situation.

2. I have no "home-cryptuser-Private.mount". What is the absolute path? Which package provides it (`rpm -qf <absolute path>`)?

3. If the above does not help, describe your steps. Start at the download of the ISO file for Fedora installation.

Comment 8 Zdenek Pytela 2022-04-21 18:51:16 UTC
When pam is configured:
https://wiki.archlinux.org/title/ECryptfs#Auto-mounting

it starts to work. If you wish, you can try the F36 testing package:

https://github.com/fedora-selinux/selinux-policy/pull/1105
Checks -> Details -> Artifacts -> rpms

It should also be a part of the next build.

Comment 9 Zdenek Pytela 2022-04-21 19:03:18 UTC
*** Bug 2009954 has been marked as a duplicate of this bug. ***

Comment 10 René Genz 2022-04-21 23:19:36 UTC
(In reply to Zdenek Pytela from comment #8)
> When pam is configured:
> https://wiki.archlinux.org/title/ECryptfs#Auto-mounting
> 
> it starts to work. If you wish, you can try the F36 testing package:
> 
> https://github.com/fedora-selinux/selinux-policy/pull/1105

Tested on Fedora 36. It fixes the problem for me. Thank you!

Comment 11 Zdenek Pytela 2022-04-27 13:39:01 UTC
*** Bug 1997457 has been marked as a duplicate of this bug. ***

Comment 12 Fedora Update System 2022-06-07 09:25:29 UTC
FEDORA-2022-9e53cb5027 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-9e53cb5027

Comment 13 Fedora Update System 2022-06-08 01:20:19 UTC
FEDORA-2022-9e53cb5027 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-9e53cb5027`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9e53cb5027

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Fedora Update System 2022-06-23 03:13:51 UTC
FEDORA-2022-9e53cb5027 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.