Description of problem: https://lore.kernel.org/selinux/819a099c-8d9d-5e07-7f3a-c7863254ce92@tycho.nsa.gov/T/#m9d2a65850abf5bfb2ea4baacd384055f66f6986c for a bigger perspective. When an SElinux policy is being built, it can be set to allow or deny unknown classes and permissions. While Fedora defines "context" class, there are 3rd party policies like the one used in kernel/scripts/selinux which don't define this class but they are built with handle unknown set to allow. pam_selinux directly calls string_to_security_class(), string_to_av_perm(), and security_compute_av() instead of using selinux_check_access(), so it doesn't honor allow_unknown presently and mls_range_allowed() fails even when there's a policy with "allow" unknown classes. Could be pam_selinux changed in order to check security_deny_unknown() and handle failures of string_to_security_class()/string_to_av_perm() accordingly? It should be just a matter of adding calls to security_deny_unknown() in the error handling paths for both string_*() mapping functions and returning success instead of failure if it returns 0.
What about the option of using selinux_check_access()? Wouldn't it be better? The patch would be slightly bigger but it would avoid adding unnecessary logic into the pam_selinux.
Thanks would be better, thanks
... at least, i think it would.
Stephen mentions overhead of an AVC as a possible reason not to use selinux_check_access(). If that overhead is negligible or otherwise not such a big deal, then I would prefer using selinux_check_access() as this might simplify the code and make it more robust.
According to the code and my tests, there's approximately 32K memory overhead for libselinux userspace AVC when selinux_check_access() is used. So if it doesn't matter, itseems to be better to use selinux_check_access() as it would simplify the code. I'll try to prepare a patch for that.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
I think that I have a solution for this bug but I'd like to test it first. Could you please indicate me a simple way of testing happy and unhappy paths?
I am not sure if the following is considered simple, and if is even a conclusive test, but If you provide me with s scratch built then I can test it as well: remove the "context {contains translate}" access vector and any references to it from the policy. then, assuming "handle unknown" is set to allow, try to log in with ssh. If SSH blocks the login then it does not work. If SSH allows the login then it works. To double check that this is really applicable, you can remove the "env_parans" option from the pam_selinux line in /etc/pam.d/sshd. That way SSH should log you in regardless because then pam_selinux does not hit the code that relies on this functionality
By the way, from what I have been told, the proper way to address this issue is to use the "selinux_check_access()" libselinux functionality in pam_selinux.
... So unless you've ported pam_selinux to use selinux_check_access(), i' am not sure if it is worth testing this iteration of yout solution.
selinux_check_access() is a function that help simplify things. It "automatically" address this issue (amongst other issues) The function is relatively new and so pam_selinux ideally should be updated to leverage this function.
Here is the scratch build for the patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=42382277
I would need something more modern, dont want to get into a downgrade rabit hole: # rpm -Uvh pam-1.3.1-22.fc31.x86_64.rpm --force error: Failed dependencies: pam >= 1.3.1-23 is needed by (installed) authselect-libs-1.2-1.fc33.x86_64
No problem. I have created a new build for rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=42403295
Thanks. From my perspective this works. It will now allow me to log in with sshd, with env_params, handle-unknown = allow, and with no context { contains }. So it handles unknown's properly now in my experience.
* master c6c51832af8e7724cfbd454daa65a6644f5b45c2 -> pam_selinux: check unknown object classes or permissions in current policy
With this patch login domains using pam requires create and bind permissions on netlabel_selinux_socket - https://bugzilla.redhat.com/show_bug.cgi?id=1813023#c6 It means that this package will need to be updated together with selinux-policy which will have builds available tomorrow (hopefully)
Correction: netlink_selinux_socket
Just installed this on rawhide, ssh login is broken with SELinux enabled.
Gwyn could you please specify what have you installed? Could you please try both pam and selinux-policy updates? https://bodhi.fedoraproject.org/updates/FEDORA-2020-d0986e01cd
On Rawhide, you need to update selinux-policy to selinux-policy-3.14.6-8.fc33 - https://koji.fedoraproject.org/koji/buildinfo?buildID=1477233
It's not yet available via dnf. Manual installation via koji works.
pam-1.3.1-24.fc32, selinux-policy-3.14.5-30.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d0986e01cd
Stumbled into this a couple of weeks later. It's good that there is a workaround but fedora 32 isn't out yet and this bug is tagged against fedora 31, a package bump there as well would be appreciated :) Thanks! -- Dominique
Because the fix requires changes in selinux-policy the decision is to fix it in F32 and Rawhide only.
Err? So you're just leaving everyone with F31 with non-working sshd? Could a pam update be pushed that reverts the behaviour requiring the policy change instead maybe? It doesn't matter for users what fix is implemented but leaving things broken on F31 doesn't seem very considerate for users... (note I just patched my policy locally so I don't really care for myself, but it took me ~10 minutes to understand what was going on because the ssh client error is anything but obvious...)
Dominique, the pam update seems to have been unpushed from the testing repo: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8c23cecdce
https://bodhi.fedoraproject.org/updates/FEDORA-2020-8c23cecdce was unpushed and pam-1.3.1-22.fc31 should not be available anymore, please downgrade your pam package # dnf info --enablerepo=updates-testing pam Installed Packages Name : pam Version : 1.3.1 Release : 18.fc31 Architecture : x86_64 Size : 2.7 M Source : pam-1.3.1-18.fc31.src.rpm Repository : @System From repo : anaconda Summary : An extensible library which provides authentication for applications URL : http://www.linux-pam.org/ License : BSD and GPLv2+ Description : PAM (Pluggable Authentication Modules) is a system security tool that : allows system administrators to set authentication policy without : having to recompile programs that handle authentication. Available Packages Name : pam Version : 1.3.1 Release : 21.fc31 Architecture : x86_64 Size : 660 k Source : pam-1.3.1-21.fc31.src.rpm Repository : updates Summary : An extensible library which provides authentication for applications URL : http://www.linux-pam.org/ License : BSD and GPLv2+ Description : PAM (Pluggable Authentication Modules) is a system security tool that : allows system administrators to set authentication policy without : having to recompile programs that handle authentication. Name : pam Version : 1.3.1 Release : 21.fc31 Architecture : i686 Size : 681 k Source : pam-1.3.1-21.fc31.src.rpm Repository : updates Summary : An extensible library which provides authentication for applications URL : http://www.linux-pam.org/ License : BSD and GPLv2+ Description : PAM (Pluggable Authentication Modules) is a system security tool that : allows system administrators to set authentication policy without : having to recompile programs that handle authentication.
Ah, that makes sense then, thanks for the update. I should try distro-sync more often, I don't think there is any other way to notice things that get unpushed otherwise.. Cheers, -- Dominique
FEDORA-2020-d0986e01cd has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d0986e01cd
FEDORA-2020-d0986e01cd has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.