service/HTTP example: why use a separate keytab?

[James Ralston]

I don't understand the example of using gssproxy for HTTP access:

[service/HTTP]
      mechs = krb5
      cred_store = keytab:/etc/gssproxy/http.keytab
      cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
      euid = 48

If I'm going to create a separate keytab file for HTTP, then wouldn't
it be easier to make the keytab file mode 0600, owner apache, group
apache, and not bother with gssproxy at all?  I mean, at that point,
what advantage is there to using gssproxy?

Wouldn't a better example be using gssproxy to permit apache to obtain
HTTP credentials (and only HTTP) out of the default system keytab
file (/etc/krb5.keytab), without having to make the keytab file
readable for apache?  Something like:

[service/HTTP]
      mechs = krb5
      cred_store = keytab:/etc/krb5.keytab
      cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
      euid = 48
      krb5_principal = HTTP

Or am I misunderstanding what krb5_principal does?

For sites that join Linux hosts to Microsoft Active Directory (and
thus create host credentials) by using "net ads join", there is a huge
advantage to keeping all of the credentials in the system keytab: if
Samba is configured to store host credentials using the system keytab
(i.e., /etc/samba/smb.conf has "kerberos method = system keytab"),
then "net ads changetrustpw" will update all host credentials.

But if different credentials are stored in different keytabs, then ~24
hours after "net ads changetrustpw" is executed, all credentials not
stored in the system keytab will become invalid.  :-(

Therefore, for Microsoft AD sites, storing all credentials in the
system keytab (/etc/krb5.keytab) is vastly preferable.  Even for sites
not using Microsoft AD, storing the credentials in a single keytab
file and using gssproxy to broker access to specific credentials seems
like a better idea than using multiple keytab files.

Is there something I'm missing here?

[Simo Sorce]

On Fri, 2015-11-20 at 14:30 -0500, James Ralston wrote:
> I don't understand the example of using gssproxy for HTTP access:
> [service/HTTP]
>   mechs = krb5
>   cred_store = keytab:/etc/gssproxy/http.keytab
>   cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
>   euid = 48
>
> If I'm going to create a separate keytab file for HTTP, then wouldn't
> it be easier to make the keytab file mode 0600, owner apache, group
> apache, and not bother with gssproxy at all?  I mean, at that point,
> what advantage is there to using gssproxy?

GSSProxy is used for privilege separation, so that if you have multiple
applications behind the same apache server then one applications cannot
attack another. If applications have access to the keytab they can
attack one another by minting tickets with arbitrary user names.
> Wouldn't a better example be using gssproxy to permit apache to obtain
> HTTP credentials (and only HTTP) out of the default system keytab
> file (/etc/krb5.keytab), without having to make the keytab file
> readable for apache?  Something like:
> [service/HTTP]
>   mechs = krb5
>   cred_store = keytab:/etc/krb5.keytab
>   cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
>   euid = 48
>   krb5_principal = HTTP
>
> Or am I misunderstanding what krb5_principal does?

Well ... embarrassingly ... you might be right if we used krb5_principal
anywhere. I am looking at master code and this looks like a forgotten
option ... oops.

So actually we just use whatever is the first principal in the keytab
for initiation.
For accepting, it doesn't matter what is the principal name, we just
look for all keys and if one matches then we use it.

Now I need to think what to do about krb5_principal:
https://fedorahosted.org/gss-proxy/ticket/155
> For sites that join Linux hosts to Microsoft Active Directory (and
> thus create host credentials) by using "net ads join", there is a huge
> advantage to keeping all of the credentials in the system keytab: if
> Samba is configured to store host credentials using the system keytab
> (i.e., /etc/samba/smb.conf has "kerberos method = system keytab"),
> then "net ads changetrustpw" will update all host credentials.

Yes, for that we have this ticket open:
https://fedorahosted.org/gss-proxy/ticket/134

But we haven't yet implemented a solution for it.
> But if different credentials are stored in different keytabs, then ~24
> hours after "net ads changetrustpw" is executed, all credentials not
> stored in the system keytab will become invalid.  :-(

Indeed, you could use a cronjob to keep keytabs in sync but I understand
this i not desirable.
For the apache case though you can definitely use the main keytab as
long as you set cred_usage = accept
> Therefore, for Microsoft AD sites, storing all credentials in the
> system keytab (/etc/krb5.keytab) is vastly preferable.  Even for sites
> not using Microsoft AD, storing the credentials in a single keytab
> file and using gssproxy to broker access to specific credentials seems
> like a better idea than using multiple keytab files.
>
> Is there something I'm missing here?

Nope, you nailed it, and it doesn't help that we know about it, because
we do not have code to deal well with it yet :-/

Simo.