Description of problem: When obligatory two-factor authentification (2FA) is activated by authselect with the function "with-pam-u2f-2fa" it is still possible to login on the console without the Yubikey. This works at the login screen and when the screen is locked. Version-Release number of selected component (if applicable): Fedora 32 LXDE x86_64 authselect-1.2.1-1.fc32.x86_64.rpm How reproducible: Always Steps to Reproduce: 1. Activate "with-pam-u2f-2fa" (e.g. execute "authselect select sssd with-pam-u2f-2fa without-nullok" by root) 2. Activate a Yubikey for a user (e.g. exectute "mkdir ~/.config/Yubico; pamu2fcfg > ~/.config/Yubico/u2f_keys" by the user and press the Yubikey button) 3. Reboot the system 4. Wait until the login manager appears 5. Press the key combination Strg-Alt-F2 to switch to a console 6. Login as the user only with the password without the Yubikey Actual results: Login without Yubikey is possible. Expected results: The login should not be possible without verification of the Yubikey or should never be possible on the console. Additional info: This is a potential security problem because someone might choose a weak password, e.g. a pin of four digits, because of the second factor (which would be ok if the 2FA would realy work). But because the 2FA can be avoided that would be highly insecure. Workaround: Remove the option "nouserok" in the files "/etc/pam.d/*". But that should only be done when login by a Yubikey is already activated for root (otherwise root cannot login anymore).
Upstream ticket: https://github.com/authselect/authselect/issues/216
The problem was discussed more detailed in relation to pam-u2f on the page https://github.com/Yubico/pam-u2f/issues/152 It became clear that there is basically a SELinux problem. Therefore I sent a mail to the SELinux mailing list (https://lists.fedoraproject.org/admin/lists/selinux.lists.fedoraproject.org/). I hope the mail will appear soon on the archive page https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/2020/8/
Because there obviously was a problem with the SELinux mailing list regarding my mail I add the main information of that mail here. The package pam-u2f of Fedora 32 uses configuration (authorization) files in the user home directories, by default "~/.config/Yubico/u2f_keys". But when one tries to login from the console that file cannot be read because of SELinux. Because of that the 2-factor authorization is not used (with the option "nouserok" of pam-u2f although it should be used) and one can login only with password and without the second factor. To get more details from SELinux Zdenek Pytela from the SELinux team suggested the following steps (in a private mail). 1. From the file /etc/audit/rules.d/audit.rules I commented out the following line: -a task,never 2. I added the following line to the end of the file: -w /etc/shadow -p w 3. I restarted the audit daemon by the following command: service auditd restart 4. I switched to the console by pressing Strg-Alt-F2, logged in with password only without the second factor, logged out and switched back to the X screen by pressing Strg-Alt-F1. 5. I executed the following command to get more information: ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today The output of the last command is in the attached file "ausearch-output.txt". The included German text "Keine Berechtigung" means "No permission". BTW: After step 4 a window with a SELinux security alert popped up which I didn't saw at former tests (maybe because of my installation of new updates in the last days). Maybe the component of this bug should be changed to SELinux and someone can choose the appropriate component.
Created attachment 1711121 [details] output of ausearch
Dietmar, Thank you for the output. It looks the yubico configuration directory has changed: we have in the policy rules for /home/[^/]+/\.yubico(/.*)? all files unconfined_u:object_r:auth_home_t:s0 /root/\.yubico(/.*)? all files system_u:object_r:auth_home_t:s0 As a quick solution, you can try chcon -R -t auth_home_t /home/anonym/.config/Yubico and login again. If that does not help, please re-run the previous steps and collect additional denials: setenforce 0 <repeat the previous steps> setenforce 1 I also wonder if you changed the value of this boolean: semanage boolean -l | grep authlogin_yubikey
Zdenek, your chcon command resolved the problem. Now I need the second factor to login on the console. The output of your semanage command is: authlogin_yubikey (aus , aus) Allow authlogin to yubikey The German "aus" means "off". Will there be an update for Fedora 32 and Fedora 31 which resolves the problem in general? Are there any more SELinux rules for Yubikey or pam-u2f so that specific changes by the developers of pam-u2f should be reported to the SELinux mailing list (or to somewhere else)?
Dietmar, The policy will be updated to resolve this issue, just based on developer availability. I am afraid I cannot answer your last question directly; in general - policy needs to be adjusted every time an important change has been made to a package.
Zdenek, until now we only discussed the reading of the file "~/.config/Yubico/u2f_keys" by the login process (when login is done on the console). But an arbitrary file in the home directory of a user can be specified by the parameter "authfile" of pam-u2f (for the parameter look at "https://developers.yubico.com/pam-u2f/"). Therefore it seems reasonable to me to define a SELinux rule that login can read any file below "/home". Do you agree? I asked about any more SELinux rules for Yubikey and pam-u2f to avoid a situation where an important file cannot be read after a change of "pam-u2f". So there are three questions from my poit of view which should be answered: 1. Which changes of pam-u2f should be reported? 2. Who should report these changes (the developer of pam-u2f who may not know much about Fedora and SELinux or the person who creates the rpm package of pam-u2f for Fedora)? 3. To whom the changes should be reported (to the SELinux mailing list or to somewhere else)? These questions may also be important for other packages.
*** Bug 1871219 has been marked as a duplicate of this bug. ***
I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/415
commit 1363710b88904f29915e39335fef0dfb673a0f70 (HEAD -> rawhide, origin/rawhide) Author: Zdenek Pytela <zpytela> Date: Mon Aug 24 14:29:15 2020 +0200 Add file context for ~/.config/Yubico Add file context specification for ~/.config/Yubico in addition to existing ~/.yubico. Update the auth_filetrans_home_content() and auth_filetrans_admin_home_content() interfaces accordingly. Resolves: rhbz#1860888
(In reply to dlippold from comment #9) > Zdenek, > > until now we only discussed the reading of the file > "~/.config/Yubico/u2f_keys" by the login process (when login is done on the > console). But an arbitrary file in the home directory of a user can be > specified by the parameter "authfile" of pam-u2f (for the parameter look at > "https://developers.yubico.com/pam-u2f/"). Therefore it seems reasonable to > me to define a SELinux rule that login can read any file below "/home". Do > you agree? Dietmar, With a fix for this bz we will assign the auth_home_t type for ~/.config/Yubico the same way as it was for ~/.yubico. We cannot assign this type for an arbitrary filename; if a custom one is used in user's environment, a local SELinux policy needs to be created, too. > I asked about any more SELinux rules for Yubikey and pam-u2f to avoid a > situation where an important file cannot be read after a change of > "pam-u2f". So there are three questions from my poit of view which should be > answered: 1. Which changes of pam-u2f should be reported? 2. Who should > report these changes (the developer of pam-u2f who may not know much about > Fedora and SELinux or the person who creates the rpm package of pam-u2f for > Fedora)? 3. To whom the changes should be reported (to the SELinux mailing > list or to somewhere else)? > > These questions may also be important for other packages. There are no strict rules. On FedoraDOCS, a general HOWTO can be found: https://docs.fedoraproject.org/en-US/quick-docs/howto-file-a-bug/ There is the selinux mailing list at lists.fedoraproject.org which matches the best when it comes to SELinux related problems. The fedora-devel list can be used when a more broad developers discussion is needed, just with the word selinux in the subject not to miss it. Anyone is welcome to report a bug. If there are AVC denials, the initial component should be selinux-policy. Proactive change reporting is also welcome as well as hard to outline, in general it is when a new SELinux permission is required: most frequently for a file, port, syscall, capability.
FEDORA-2020-740de661da has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-740de661da
FEDORA-2020-740de661da has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-740de661da` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-740de661da See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I executed the dnf command and the following two packages were installed (updated): selinux-policy-3.14.5-43.fc32.noarch selinux-policy-targeted-3.14.5-43.fc32.noarch Then I rebooted the system. But the bug still exists and the file "~/.config/Yubico/u2f_keys" is still not readable. I executed the steps dscribed in my comment above with date "2020-08-11 21:42:29 UTC". The relevant output of the ausearch command is: type=AVC msg=audit(30.08.2020 14:57:58.329:271) : avc: denied { read } for pid=1935 comm=login name=u2f_keys dev="sda2" ino=655918 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=file permissive=0 Then I executed the chcon command you gave above: chcon -R -t auth_home_t /home/anonym/.config/Yubico Now the file "~/.config/Yubico/u2f_keys" is readable. So it seems to me that the update din't change much. Which file of my Fedora system should contain the new SELinux rule (for the file "~/.config/Yubico/u2f_keys")?
This updates deals with the situation the directory does not exist, the permissions are the same as they were previously. Files in the /home directory are not automatically relabeled, so a command for restoring context needs to be run, e. g. # fixfiles onboot and reboot the system.
FEDORA-2020-740de661da has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
Zdenek, the command "fixfiles onboot" resolves the bug for me. Could that command (or even better the update of the SELinux security contexts only for the files in "/home/*/.config/" and "/root/.config/") be done automatically when the RPM packages are installed? That would fix the bug also for those users who already use "pam-u2f" and who are most seriously affected by the bug.
The updates should also be provided for Fedora 31.
Dietmar, I am afraid this is not possible. The fixfiles script, executed from a rpm scriptlet, explicitly excludes /home and /root from filesystems to relabel during update: # # Compare PREVious File Context to currently installed File Context and # run restorecon on all files affected by the differences. # diff_filecontext() { EXCLUDEDIRS="`exclude_dirs_from_relabelling`" for i in /sys /proc /dev /run /mnt /var/tmp /var/lib/BackupPC /home /tmp /dev; do [ -e $i ] && EXCLUDEDIRS="${EXCLUDEDIRS} -e $i"; done LogExcluded if [ -f ${PREFC} -a -x /usr/bin/diff ]; then TEMPFILE=`mktemp ${FC}.XXXXXXXXXX` test -z "$TEMPFILE" && exit PREFCTEMPFILE=`mktemp ${PREFC}.XXXXXXXXXX` sed -r -e 's,:s0, ,g' $PREFC | sort -u > ${PREFCTEMPFILE} sed -r -e 's,:s0, ,g' $FC | sort -u | \ /usr/bin/diff -b ${PREFCTEMPFILE} - | \ grep '^[<>]'|cut -c3-| grep ^/ | \ egrep -v '(^/home|^/root|^/tmp|^/dev)' |\ ... The reason probably is it could possibly take a really long time. Not skipping dot-directories is a good idea worth suggesting as an RFE in the policycoreutils component. If setroubleshoot is installed and the path is logged, the restorecon plugin will now suggest the restorecon action. In a perfect world, the change in the yubikey-handling package would be accompanied with a matching change in selinux-policy at the same time so that nobody notices a change.
Zdenek, if I understand you correctly the SELinux context of the files in "/home/*/.config/" can currently not be fixed (automatically) when the PRM package is installed. But wouldn't it be possible to execute the command "fixfiles onboot" when the PRM package is installed? When it would not be possible to fix the bug for the users who already use pam-u2f then there would be a bug in the process of installation of RPM packages without doubt.
Dietmar, The fixfiles onboot command leads to relabeling all filesystems. Some systems may then boot reasonably long time as all mounted filesystems are checked; even relabeling just /home can take time, and as this is not expected, we avoid such actions. For new installations of pam-u2f or for users without ~/.config/Yubico existing, it should work out of the box with the updates selinux-policy package. For others, invoking one of the commands for relabeling is required.
Zdenek, the problem is that probably most of the user of pam-u2f don't know of this bug and don't know that they have to relabel their directories. The general problem of the update of SELinux contexts after modifying the SELinux policy is still discussed on https://lore.kernel.org/selinux/CAEjxPJ5BczUFZ82C4bnioSiFLwqv4uvBaGP1afmAf4+amOraAQ@mail.gmail.com/T/#t after a discussion on https://github.com/SELinuxProject/selinux/issues/263 . But that would probably not result in a fix for this concrete bug. Would it be possible to add the following specific command (or a equivalent one) to the next RPM package of selinux-policy so that this command is executed when the package is installed? fixfiles /root/.config/Yubico/ /home/*/.config/Yubico/ This command would not need much time for execution.
It would also be sufficient to add the above mentioned command to the RPM package of "pam-u2f".