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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland