On Mon, 2020-10-19 at 12:40 -0400, Jason Keltz wrote:
On 10/19/2020 10:55 AM, Simo Sorce wrote:
> On Mon, 2020-10-19 at 10:14 -0400, Jason Keltz wrote:
> > On 10/19/2020 8:59 AM, Simo Sorce wrote:
> >
> > > On Fri, 2020-10-16 at 16:39 -0400, Jason Keltz wrote:
> > > > Hi.
> > > >
> > > > I've been trying to get gssproxy working with httpd and
mod_auth_gssapi
> > > > on CentOS 7.8. Albeit, I'm not using the httpd from CentOS, but
a later
> > > > 2.4.39.
> > > >
> > > > I setup the httpd keytab. I setup mod_auth_gssapi and was able to
> > > > access my page with Kerberos auth no problem at all.
> > > >
> > > > Next, I wanted to get things working with gssproxy.
> > > >
> > > > I created /etc/gssproxy/80-httpd.conf
> > > >
> > > > [service/HTTP]
> > > > mechs = krb5
> > > > cred_store = keytab:/xconf/httpd/keytab/httpd-www-svc.keytab
> > > > cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
> > > > euid = www
> > > >
> > > > My web user is "www".
> > > >
> > > > My keytab file is in the given location. I change permission to
600,
> > > > owned by root.
> > > >
> > > > I added to the Service section of /etc/systemd/system/httpd.service:
> > > >
> > > > Environment=GSS_USE_PROXY=yes
> > > >
> > > > I restart httpd and gssproxy.
> > > >
> > > > My test protected page is under a .htaccess as follows:
> > > >
> > > > AuthType GSSAPI
> > > > AuthName "GSSAPI Login"
> > > > GssapiBasicAuth On
> > > > GssapiLocalName on
> > > > Require valid-user
> > > >
> > > > When I visit the page and I don't have a ticket, I get prompted
for my
> > > > username and password. Access is denied.
> > > >
> > > > When I visit my page Apache outputs:
> > > >
> > > > [Thu Oct 15 15:04:12.311614 2020] [auth_gssapi:error] [pid 28584:tid
> > > > 13995355614
> > > > 1824] [client 130.63.97.125:57910] GSS ERROR
gss_acquire_cred[_from]()
> > > > failed to
> > > > get server creds: [Unspecified GSS failure. Minor code may
provide
> > > > more inform
> > > > ation (Keytab FILE:/etc/krb5.keytab is nonexistent or empty)]
> > > >
> > > > ... so I know that it's not really using gssproxy because if it
was, it
> > > > wouldn't be looking at /etc/krb5.keytab.
> > > >
> > > > I enabled debugging on gssproxy, level 3, but when I access the
page,
> > > > gssproxy doesn't log anything. This is printed when I start
gssproxy
> > > > and doesn't change:
> > > >
> > > > [2020/10/15 23:23:26]: Service: HTTP, Keytab:
> > > > /xconf/httpd/keytab/httpd-www-svc.keytab, Enctype: 23
> > > > [2020/10/15 23:23:26]: Service: nfs-server, Keytab:
/etc/krb5.keytab,
> > > > Enctype: 17
> > > > [2020/10/15 23:23:26]: Service: nfs-client, Keytab:
/etc/krb5.keytab,
> > > > Enctype: 17
> > > > [2020/10/15 23:23:26]: Debug Enabled (level: 3)
> > > > [2020/10/15 23:23:26]: Problem with kernel communication! NFS
server
> > > > will not work
> > > > [2020/10/15 23:23:26]: Failed to get peer's SELinux context
(92:Protocol
> > > > not available)
> > > > [2020/10/15 23:23:26]: Client connected (fd = 10)[2020/10/15
23:23:26]:
> > > > (pid = 24902) (uid = 0) (gid = 0)[2
> > > >
> > > > I assume the "Problem with kernel communication" error is
just because
> > > > there is no nfs-server running here, but the gssproxy file exists.
> > > >
> > > > Of course if I go back and insert into the .htaccess:
> > > >
> > > > GssapiCredStore keytab:/xconf/httpd/keytab/httpd-www-svc.keytab
> > > >
> > > > ... and I make the file readable by "www" then it works,
but that, of
> > > > course isn't using gssproxy either.
> > > >
> > > > I read a bug report on Redhat about there being an issue with using
> > > > "GssapiLocalName on" so I removed that and it didn't
make a difference.
> > > >
> > > > So what is the magic bit that I'm missing to tell httpd to
actually use
> > > > gssproxy? I thought the only thing was the USE_GSS_PROXY=yes
> > > >
> > > > Does the application itself need to be aware of gssproxy, or is that
> > > > hidden from the application?
> > > >
> > > > I even tried adding to the httpd.service:
> > > >
> > > > Environment=KRB5_TRACE=/tmp/log
> > > >
> > > > ... hoping this would give me *something* but the file didn't
even get
> > > > created.
> > > >
> > > > Any feedback that you can provide would be helpful.
> > > Hi Jason,
> > > I assume you have a custom install of gssproxy as well here.
> > >
> > > So 2 questions.
> > > 1) what libkrb5 version do you have installed ?
> > > 2) Have you configured gssproxy as a GSSAPI mechanism ?
> > >
> > > See man 8 gssproxy-mech for more info on how to do (2).
> > Hi Simo,
> >
> > Thanks for your message.
> >
> > I'm actually just using the OS provided gssproxy. I don't have a
custom
> > install of that.
> >
> > In terms of libkrb5, in /usr/lib64 I see:
> >
> > lrwxrwxrwx 1 root root 14 May 6 12:22 /usr/lib64/libkrb5.so ->
> > libkrb5.so.3.3
> > lrwxrwxrwx 1 root root 14 May 6 12:22 /usr/lib64/libkrb5.so.3 ->
> > libkrb5.so.3.3
> > -rwxr-xr-x 1 root root 967760 Mar 31 2020 /usr/lib64/libkrb5.so.3.3
> > lrwxrwxrwx 1 root root 21 May 6 12:22 /usr/lib64/libkrb5support.so
> > -> libkrb5support.so.0.1
> > lrwxrwxrwx 1 root root 21 May 6 12:22
> > /usr/lib64/libkrb5support.so.0 -> libkrb5support.so.0.1
> > -rwxr-xr-x 1 root root 67104 Mar 31 2020 /usr/lib64/libkrb5support.so.0.1
> >
> > I see /etc/gss/mech.d/gssproxy.conf containing:
> >
> > # GSS-API mechanism plugins
> > #
> > # Mechanism Name Object Identifier Shared Library
> > Path Other Options
> > gssproxy_v1 2.16.840.1.113730.3.8.15.1
> > /usr/lib64/gssproxy/proxymech.so <interposer>
> >
> > ... which is just the default setup, but I don't see any reason why it
> > wouldn't work at this point.
> Ah, sorry, I just realized this is for password based authentication.
>
> Unfortunately hand-over for that operation is not supported in the
> gssproxy version you are using.
>
> In fact it is something I am working on upstream krb5 now, to provide a
> proper interface via gss_acquire_cred_from() that will allow me to
> change proxy to allow password based validation to be performed via the
> proxy.
>
> So I am afraid what you are experiencing is expected at this time, for
> password based authentication apache needs direct access to a key it
> can use.
Hi Simo,
This is unfortunate. I've spent a lot time trying to make this work.
However, it's good to know that it was just something I wasn't doing right.
What could a regular user do with the keytab file if they got a hold of
it - run a web server which purports to be the web server?
They can:
- impersonate any user to the server
- impersonate the server
- acquire tickets and contact other services using the server's
identity.
Definitely not recommended to hand untrusted users a keytab.
However you do not need to use the server's key for password
verification.
You could use a key specifically used for password verification only,
and not used for any other purposes.
You should make sure such key cannot acquire credentials either, by
properly marking the principal in the KDC, to protect separate service
with lax configuration on principal mappings.
So you could create a principal like:
HTTP/password.verification.only(a)YOUR.REALM
And extract a key for that principal in the keytab you then use in
mod_auth_gssapi authentication.
In this case you must *not* set an acceptor name, so that whatever is
in the keytab will be used.
You will keep gssproxy current configuration to protect the actual
service key instead for when users present valid GSSAPI credentials and
do normal negotiation.
HTH,
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc