On 5/10/21 11:21 AM, Alexander Bokovoy wrote:
> On ma, 10 touko 2021, Harry G. Coin wrote:
>>
>> On 5/10/21 10:30 AM, Alexander Bokovoy wrote:
>>> On ma, 10 touko 2021, Harry G. Coin wrote:
>>>>
>>>> On 5/10/21 9:55 AM, Alexander Bokovoy wrote:
>>>>> On ma, 10 touko 2021, Harry G. Coin wrote:
>>>>>>
>>>>>> On 5/10/21 8:31 AM, Alexander Bokovoy wrote:
>>>>>>> On su, 09 touko 2021, Harry G. Coin via FreeIPA-users wrote:
>>>>>>>> On f34, freeipa-server 4.9.3-2: Upon choosing any action using a
>>>>>>>> logged-in UI that has been left idle for some hours, browsers
>>>>>>>> lock a
>>>>>>>> display 'internal server error' (at least on firefox) instead of a
>>>>>>>> log-in page, or the desired page. No actions on the server side
>>>>>>>> will
>>>>>>>> clear it. The only work-around is to delete the browser cookies
>>>>>>>> and
>>>>>>>> cached data, and after navigating to the UI the login page appears
>>>>>>>> normally.
>>>>>>>
>>>>>>> It looks like the cache entry for user authentication which is
>>>>>>> stored
>>>>>>> encrypted on the server side cannot be decrypted anymore. This
>>>>>>> might
>>>>>>> happen when you have rebooted a server between authenticating the
>>>>>>> user
>>>>>>> and its session's expiration. There are two keys here:
>>>>>>>
>>>>>>> - mod_auth_gssapi uses ipasession.key (in /etc/httpd/alias in
>>>>>>> Fedora)
>>>>>>> for encrypting the cookie session
>>>>>>>
>>>>>>> - GSS-Proxy uses own service keytab or an in-memory key to encrypt
>>>>>>> Kerberos credentials in a ccache generated and stored on the
>>>>>>> server
>>>>>>> which corresponds to the content stored in the cookie session
>>>>>>>
>>>>>>> If you'd restart GSS-Proxy or reboot the system, the ccache
>>>>>>> generated
>>>>>>> and stored on the server side by GSS-Proxy would not be possible to
>>>>>>> decrypt in case an ephemeral in-memory key was used.
>>>>>>>
>>>>>>> Can you enable IPA server-side debugging in case this happens to
>>>>>>> see if
>>>>>>> we can handle an error from mod_auth_gssapi better?
>>>>>>>
>>>>>> I think blocking access to the freeipa-ui until all users delete all
>>>>>> browser cookies and cached data every time freeipa is rebooted is
>>>>>> probably not a good thing.
>>>>>>
>>>>>> In my test case, freeipa-server is in a VM using a virtio-fs as the
>>>>>> boot/root filesystem. The virtio-fs folks haven't quite managed to
>>>>>> solve SELinux problems when their file system is the root device,
>>>>>> so for
>>>>>> the time being I set SELinux to permissive. Serendipity might have
>>>>>> generated a clue, as follows:
>>>>>>
>>>>>> # cat /etc/ipa/server.conf
>>>>>>
>>>>>> [global]
>>>>>> certmonger_wait_timeout=1200
>>>>>> startup_timeout = 720
>>>>>> startup_traceback = True
>>>>>> debug=True
>>>>>>
>>>>>> # journalctl -f
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> May 10 09:33:40 registry1.1.quietfountain.com [1435]: GSSAPI client
>>>>>> step 1
>>>>>> May 10 09:33:45 registry1.1.quietfountain.com audit[676]: AVC avc:
>>>>>> denied { lock } for pid=676 comm="gssproxy"
>>>>>> path="/var/lib/ipa/gssproxy/http.keytab" dev="virtiofs" ino=745470
>>>>>> scontext=system_u:system_r:gssproxy_t:s0
>>>>>> tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
>>>>>> permissive=1
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> May 10 09:33:46 registry1.1.quietfountain.com [1435]: GSSAPI client
>>>>>> step 1
>>>>>> May 10 09:33:46 registry1.1.quietfountain.com [1435]: GSSAPI client
>>>>>> step 1
>>>>>> ...
>>>>>>
>>>>>>
>>>>>> It's quite repeatable, every refresh on the browser generates the
>>>>>> AVC
>>>>>> line above (amid the log being cluttered with 'GSSAPI client step
>>>>>> 1'...
>>>>>
>>>>> Thanks, this is helpful. In your case
>>>>> /var/lib/ipa/gssproxy/http.keytab
>>>>> has unlabeled_t context and that access is obviously not allowed.
>>>>>
>>>>> # ls -lZ /var/lib/ipa/gssproxy/
>>>>> total 4
>>>>> -rw-------. 1 apache apache unconfined_u:object_r:ipa_var_lib_t:s0
>>>>> 178
>>>>> May 7 09:27 http.keytab
>>>>>
>>>>> Does restorecon help to relable? Perhaps, this is due to
>>>>> installing in
>>>>> SELinux off?
>>>>
>>>>
>>>> Because selinux is set to permissive, what would not be allowed if
>>>> SElinux was set to enforcing appears in the log. However,
>>>> everything is
>>>> allowed owing to the permissive setting. So in this instance, SELinux
>>>> didn't block anything, but generated a clue as to what gets attempted
>>>> upon failed ui accesses.
>>>
>>> Sure, I know that. What I am trying to understand is whether you can
>>> relabel the path that is located on virtio-fs mount. Since we have
>>> proper fcontext associated with /var/lib/ipa/gssproxy, it needs to be
>>> labeled to allow proper SELinux work:
>>>
>>> # matchpathcon /var/lib/ipa/gssproxy/
>>> /var/lib/ipa/gssproxy system_u:object_r:ipa_var_lib_t:s0
>>>
>>> I suspect this is really a use of a file system that is not really
>>> compatible with SELinux here. We are not going to add a rule that would
>>> allow gssproxy_t context to access unlabeled_t files in a default IPA
>>> policy. Either your OS supports SELinux in all components you are using
>>> or you are not really benefitting from the SELinux enforcements.
>>>
>>
>> OK, I'll try that. However, isn't the entire SELinux question unrelated
>> to the main topic of concern here? Given that at most SELinux
>> complains but doesn't obstruct anything in this instance, what can be
>> done about forcing the deletion of cookies and cached data in order to
>> permit UI usage/login?
>
> If GSS-Proxy couldn't read the keytab it is supposed to use, it cannot
> use a stable key for encryption, thus failing to decrypt ccache material
> from the older sessions. The behavior is fully related.
>
> Are you running this system in permissive from start or did you switch
> to permissive fater the problems started to occur? If the latter, then
> chances are that you already had client sessions encrypted with
> ephemeral keys, thus the problem when you have allowed GSS-Proxy to
> access the stable key by switching to permissive mode.
>
This was/is the installation sequence, on otherwise stock f34 workstation:
1) #dnf install <all the freeipa world>
2) #setenforce permissive
3) #sed s/^SELINUX=enforcing/SELINUX=permissive/ -i /etc/selinux/config
4) #ipa-server-install <options>
...
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
