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>
...