gssproxy security, configuration and life-cycle questions

[Andrew J. Romero]

Hi

In my environment using gssproxy, on our NFS client systems,
facilitates the reliable operation of Kerberos secured
NFS I/O by non-interactive processes.

Prior to learning about gssproxy, we used a somewhat
"kludgy" scheme, to obtain Kerberos credentials for 
non-interactive processes, involving cron jobs to
kinit at regular intervals. Problems with 
gss kernel contexts ( requiring client reboots )
were much more common before gssproxy.

I noticed that in newer versions of Linux 
( for example: Red Hat Enterprise v9 ), the 
paramter  use-gss-proxy 
(in the [gssd] section of /etc/nfs.conf file )
no longer exists.

I have also read that some security specialists
determined that gssproxy increases security risk.
And they are recommending that use of gssproxy be discontinued.
( SEE:  https://www.stigviewer.com/stig/red_hat_enterprise_linux_9/2023-12-01/findin... )

Questions:

1) Why did the use-gss-proxy configuration parameter
   disappear ?

2) What is the nature and severity of the security risk/s
   associated with gssproxy ( on NFS clients ) ?

3) Is there a way for users to mitigate the security risk without
   discontinuing the use of gssproxy ?

4) Will the gssproxy code be modified to eliminate the security risk ?

5) What is the expected 5 - 10 year plan for active gssproxy development ?

6) If the plan is to discontinue active development, are there other active
   living projects that will provide the same functionality ?

Thanks

Andy Romero
Fermilab / ITD

[Alexander Bokovoy]

On Чцв, 13 сак 2025, Andrew J. Romero via gss-proxy wrote:
> Hi
>
> In my environment using gssproxy, on our NFS client systems,
> facilitates the reliable operation of Kerberos secured
> NFS I/O by non-interactive processes.
>
> Prior to learning about gssproxy, we used a somewhat
> "kludgy" scheme, to obtain Kerberos credentials for
> non-interactive processes, involving cron jobs to
> kinit at regular intervals. Problems with
> gss kernel contexts ( requiring client reboots )
> were much more common before gssproxy.
>
> I noticed that in newer versions of Linux
> ( for example: Red Hat Enterprise v9 ), the
> paramter  use-gss-proxy
> (in the [gssd] section of /etc/nfs.conf file )
> no longer exists.
>
> I have also read that some security specialists
> determined that gssproxy increases security risk.
> And they are recommending that use of gssproxy be discontinued.
> ( SEE:  https://www.stigviewer.com/stig/red_hat_enterprise_linux_9/2023-12-01/findin... )

The particular STIG definition above is very vague and not to the point.
While it is a good approach to minimize your attack surface by reducing
number of unrelated components installed on the system, the example of
gssproxy and argument that it is easier to exfiltrate credentials when
gssproxy is used is weak.

Consider, for example, a case of Kerberos keytabs. System-wide keytab
(/etc/krb5.keytab) typically is accessible to root only already. Without
gssproxy one will have to give access to it for every application that
needs a machine account, so the attack surface is an every daemon (sshd,
rpc.gssd, smbd/winbindd, sssd, etc.) that needs access to the host
keytab. The keys will be possible to exfiltrate by simply getting into
the address space of that particular application.

gssproxy runs as a separate service and can own all these keytabs itself
within the namespaces it runs. It means that you can, for example,
utilize systemd credentials feature to encrypt keytabs at rest and tie
that encryption to some hardware mechanism (TPM2, for example). This
would work transparently for gssproxy's use of Kerberos keytabs. Actual
applications requesting Kerberos tickets through gssproxy would not need
to know how these keytabs are stored.
> Questions:
> Why did the use-gss-proxy configuration parameter
>
> disappear ?

I'm looking at the upstream nfs-utils and 'use-gss-proxy' parameter is
present there. Its defaults did not change since its introduction in 2018.

use-gss-proxy parameter is not documented in rpc.gssd(8) man page but
mentioned in passing in nfs.conf(5).

However, it is not required to be present. GSS_USE_PROXY=yes can be set
in the systemd service environment and will lead to the same result.
Internally, use-gss-proxy=1 is equivalent to setting GSS_USE_PROXY=yes
in the gssd's process environment.
> What is the nature and severity of the security risk/s
>
> associated with gssproxy ( on NFS clients ) ?

None compared to not using gssproxy.

The concept of gssproxy is to make sure applications don't need to have
access to actual Kerberos keytabs and credentials in credential caches.
This is achieved by:

- only giving access to keytabs to gssproxy daemon

- encrypting cached credentials in the credentials caches on the
    application side with a key known to gssproxy only.

As a result, an application using GSS-API can request tickets without
having access to actual key material. However, these tickets aren't
exposed to the applications themselves as with raw Kerberos API.
Instead, they are decoded inside GSS-API implementation (thanks to the
interposer plugin that gssproxy implements) and used within the GSS-API
Kerberos mechanism implementation. Applications might try to export
credentials but they will be encrypted with the key that only available
to gssproxy.

gssproxy also makes access to its socket more controllable using a
process peer credentials', SELinux context and other system properties
that cannot be easily manipulated.

In my opinion, gssproxy greatly improves security of long term
principal keys and user credentials.
> Is there a way for users to mitigate the security risk without
>
> discontinuing the use of gssproxy ?
> Will the gssproxy code be modified to eliminate the security risk ?
>
> What is the expected 5 - 10 year plan for active gssproxy development ?

gssproxy is a stable and mature application. There are few changes
envisioned that might come to help environments that run gssproxy in
user systemd sessions. Other than that, most problems already solved and
evolution would follow GSS-API specification evolution.
> If the plan is to discontinue active development, are there other active
>
> living projects that will provide the same functionality ?
>
> Thanks
>
> Andy Romero
> Fermilab / ITD
>
> -- 
> _______________________________________________
> gss-proxy mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Simo Sorce]

Hi Andrew,

answers in line.

On Thu, 2025-03-13 at 01:26 +0000, Andrew J. Romero via gss-proxy
wrote:
> Hi
>
> In my environment using gssproxy, on our NFS client systems,
> facilitates the reliable operation of Kerberos secured
> NFS I/O by non-interactive processes.
>
> Prior to learning about gssproxy, we used a somewhat
> "kludgy" scheme, to obtain Kerberos credentials for 
> non-interactive processes, involving cron jobs to
> kinit at regular intervals. Problems with 
> gss kernel contexts ( requiring client reboots )
> were much more common before gssproxy.
>
> I noticed that in newer versions of Linux 
> ( for example: Red Hat Enterprise v9 ), the 
> paramter  use-gss-proxy 
> (in the [gssd] section of /etc/nfs.conf file )
> no longer exists.
>
> I have also read that some security specialists
> determined that gssproxy increases security risk.
> And they are recommending that use of gssproxy be discontinued.
> ( SEE:  https://www.stigviewer.com/stig/red_hat_enterprise_linux_9/2023-12-01/findin... )

DISA Stigs are very specific recommendations for certain scenarios, and
can't be taken out of context. In the case where a system is not
supposed to have any cron job and all users always have valid
credentials at all time it may make sense to reduce the number of 
services running, regardless of their security, I believe this is the
context in which that recommendation was written.

It is not an assertion on the security or insecurity of gssproxy itself
(and if that is the intention then the statement is incorrect and
should be addressed with DISA).

In your case you *do* run services that need non-interactive
credentials, therefore in your case gssproxy could be a net benefit in
security posture because, correctly implemented, allows for privilege
separation where the less privileged cron job does not have access to
credentials that could be exploited for higher access elsewhere.
> Questions:
> Why did the use-gss-proxy configuration parameter
> disappear ?

I see it in the last package I can download internally, perhaps a local
configuration change?
> What is the nature and severity of the security risk/s
> associated with gssproxy ( on NFS clients ) ?

See above.
> Is there a way for users to mitigate the security risk without
> discontinuing the use of gssproxy ?

Yes, you need to interpret hardening recommendations in the context of
your usage, and apply only those that fit the context.
> Will the gssproxy code be modified to eliminate the security risk ?

There is *no known* security risk in running gss-proxy and several
*known* security mitigations in running it in certain scenarios.

The *whole* point of gssproxy, the reason for its existence, is to
implement privilege separation to mitigate the risk of giving access to
sensitive credentials to processes that do not strictly need access to
those credentials.
> What is the expected 5 - 10 year plan for active gssproxy development ?

Gssproxy has achieved the maturity currently required to implement its
primary function. Further development will be contingent to changes in
the GSS protocol, or the krb5 libraries, both also very mature and
stable with no expected changes in the near term, or requests for
features.
> If the plan is to discontinue active development, are there other active
> living projects that will provide the same functionality ?

There are no other projects that provide privileges seaparation for
gssapi usage, and this project is currently maintained at a
satisfactory level, given its goals.

If there are shortcomings of this project that you can identify we can
evaluate if they fall within the purview of gssproxy and whether they
should be addressed.

HTH,
Simo.
> Thanks
>
> Andy Romero
> Fermilab / ITD