8:24 a.m.
I'm sorry, I'm very far from an expert in GSS/krb5. In particular, I've
never used NFS and gssd together, so I have no personal experience.
Maybe someone else on the list can help?
For questions like this, our default has been "what does knfsd do?" Do
you happen to know if knfsd accepts "shorthostname(a)REALM.COM" as a root
user?
Daniel
On 1/18/20 11:50 PM, Pushpesh Sharma wrote:
Hi All,
Any pointers are appreciated..
-pushpesh
*From:* Pushpesh Sharma <pushpeshs(a)vmware.com>
*Sent:* Thursday, January 16, 2020 7:45 PM
*To:* devel(a)lists.nfs-ganesha.org
*Subject:* [NFS-Ganesha-Devel] Default KRB Principal name with new
rpc.gssd
Hi All,
We are trying to use ganehsa with KRB. On NFS client centos7.5 we are
joining Active Directory based using sssd(AD based KRB Realm). For
root user we are getting krb ticket using kinit and valid AD user.
Client principal while joining domain using sssd a default principal
of shorthostname$(a)REALM.COM <mailto:shorthostname$@REALM.COM> is
always generated. gss.rpcd by default send this principal as principal
user name to ganesha server. Client do have other principal like
nfs/client_fdqn(a)REALM.COM <mailto:nfs/client_fdqn@REALM.COM>. But as
per rpc.gssd documentation <mailto:rpc.gssd%20documentation> as well
first choice would be shorthostname$(a)REALM.COM
<mailto:shorthostname$@REALM.COM>.
Due to this server always recognize root user as someone else i.e.
shorthostname$(a)REALM.COM <mailto:shorthostname$@REALM.COM>.
We do see in src/idmapper/idmapper.c
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub....
handling for mapping three principal patterns nfs/* , root/*, host/*
to uid=0, gid=0. So this left shorthostname$(a)REALM.COM
<mailto:horthostname$@REALM.COM> principal not being recognized as root.
We are of the opinion that doing a small fix in above idmapper code to
add this pattern as well can fix this issue.
But we wanted to know any security concern around it? Or if the client
behavior can be change in any way, so we don’t need this fix?
If we try removing this shorthostname$(a)REALM.COM
<mailto:shorthostname$@REALM.COM>principal after domain join, sssd
cannot be re-loaded and complains about not finding this principal.
Thanks
-pushpesh
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
4:19 a.m.
New subject: Default KRB Principal name with new rpc.gssd
Hi All,
I was able to verify the KNFSD behaviour on Centos7.5(both server and client), here is my
understanding:-
1. KNFSD moved from idmap.conf approach 2-3 years back. It by default uses gssproxy. As
per doumenttation " between using the classic rpc.scvgssd protocol and the new
gssproxy protocol is determined once at runtime. Once the kernel "chooses" the
method it cannot be changed. A reboot will be necessary."
2. As kernel NFS client by default still uses rpc.gssd and not gssproxy. So the server
falls back to rpc.scvgssd and idmapd.
3. As no static mapping exist for any user on KNFS server, So out of box experience for
CentOs7.5 kernel server is root user will be quashed to nobody.
4. As per this doc the possible approached to solve this problem is using gssproxy at
client side
https://pagure.io/gssproxy/blob/master/f/docs/NFS.md
and the possible ways are:
a.) Keytab based Client Initiation
b.) User Impersonation via Constrained Delegation
5. NFS ganesha still based on idmap approach. So even above suggested way of using
gssproxy is not available. So rely on this static mapping for root
user(https://github.com/nfs-ganesha/nfs-ganesha/blob/8e59f7976aae29c6b4ed...
6. Now this static idmapping needs to be updated based on new rpc.gssd behaviour which
will always give priority to shothostname$(a)REALM.COM. SSSD with AD id provider ensure that
this principle is always present.
7. Simplest fix is add one more pattern to match on the list given above. Any principle
which present the principle as someshorthostname$(a)REALM.COM will be assigned to uid=0 or
gid=0.
8. The security concerns on this pattern being misused:-
a.) First any vulnerability also applies to other patterns as well. But as we know
getting any valid ticket for these principle requires password and authentication and
authorization from Kerberos. So such possibility is null if we trust Kerberos.
b.) Other users on the system using the machine credential? It is not possible as rpc.gssd
allow this privilege to use machine credential to only uid=0(root). Even this can be
controlled by "/etc/nfs.conf", option use-machine-creds.
So in summary, this needs to be fix in ganehsa and there is no current comparable code
that matches with this in KNFSD as they are using different methods for it.
-pushpesh
On 20/01/20, 7:55 PM, "Daniel Gryniewicz" <dgryniew(a)redhat.com> wrote:
I'm sorry, I'm very far from an expert in GSS/krb5. In particular, I've
never used NFS and gssd together, so I have no personal experience.
Maybe someone else on the list can help?
For questions like this, our default has been "what does knfsd do?" Do
you happen to know if knfsd accepts "shorthostname(a)REALM.COM" as a root
user?
Daniel
On 1/18/20 11:50 PM, Pushpesh Sharma wrote:
Hi All,
Any pointers are appreciated..
-pushpesh
*From:* Pushpesh Sharma <pushpeshs(a)vmware.com>
*Sent:* Thursday, January 16, 2020 7:45 PM
*To:* devel(a)lists.nfs-ganesha.org
*Subject:* [NFS-Ganesha-Devel] Default KRB Principal name with new
rpc.gssd
Hi All,
We are trying to use ganehsa with KRB. On NFS client centos7.5 we are
joining Active Directory based using sssd(AD based KRB Realm). For
root user we are getting krb ticket using kinit and valid AD user.
Client principal while joining domain using sssd a default principal
of shorthostname$(a)REALM.COM <mailto:shorthostname$@REALM.COM> is
always generated. gss.rpcd by default send this principal as principal
user name to ganesha server. Client do have other principal like
nfs/client_fdqn(a)REALM.COM <mailto:nfs/client_fdqn@REALM.COM>. But as
per rpc.gssd documentation <mailto:rpc.gssd%20documentation> as well
first choice would be shorthostname$(a)REALM.COM
<mailto:shorthostname$@REALM.COM>.
Due to this server always recognize root user as someone else i.e.
shorthostname$(a)REALM.COM <mailto:shorthostname$@REALM.COM>.
We do see in src/idmapper/idmapper.c
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub....
handling for mapping three principal patterns nfs/* , root/*, host/*
to uid=0, gid=0. So this left shorthostname$(a)REALM.COM
<mailto:horthostname$@REALM.COM> principal not being recognized as root.
We are of the opinion that doing a small fix in above idmapper code to
add this pattern as well can fix this issue.
But we wanted to know any security concern around it? Or if the client
behavior can be change in any way, so we don’t need this fix?
If we try removing this shorthostname$(a)REALM.COM
<mailto:shorthostname$@REALM.COM>principal after domain join, sssd
cannot be re-loaded and complains about not finding this principal.
Thanks
-pushpesh
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
4:32 a.m.
New subject: Default KRB Principal name with new rpc.gssd
Hi Frank , Jeff, Daniel,
Your response is highly appreciated.
Thanks
-pushpesh
On 19/02/20, 3:49 PM, "Pushpesh Sharma" <pushpeshs(a)vmware.com> wrote:
Hi All,
I was able to verify the KNFSD behaviour on Centos7.5(both server and client), here is
my understanding:-
1. KNFSD moved from idmap.conf approach 2-3 years back. It by default uses gssproxy.
As per doumenttation " between using the classic rpc.scvgssd protocol and the new
gssproxy protocol is determined once at runtime. Once the kernel "chooses" the
method it cannot be changed. A reboot will be necessary."
2. As kernel NFS client by default still uses rpc.gssd and not gssproxy. So the server
falls back to rpc.scvgssd and idmapd.
3. As no static mapping exist for any user on KNFS server, So out of box experience
for CentOs7.5 kernel server is root user will be quashed to nobody.
4. As per this doc the possible approached to solve this problem is using gssproxy at
client side
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure....
and the possible ways are:
a.) Keytab based Client Initiation
b.) User Impersonation via Constrained Delegation
5. NFS ganesha still based on idmap approach. So even above suggested way of using
gssproxy is not available. So rely on this static mapping for root
user(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi...
6. Now this static idmapping needs to be updated based on new rpc.gssd behaviour which
will always give priority to shothostname$(a)REALM.COM. SSSD with AD id provider ensure that
this principle is always present.
7. Simplest fix is add one more pattern to match on the list given above. Any
principle which present the principle as someshorthostname$(a)REALM.COM will be assigned to
uid=0 or gid=0.
8. The security concerns on this pattern being misused:-
a.) First any vulnerability also applies to other patterns as well. But as we know
getting any valid ticket for these principle requires password and authentication and
authorization from Kerberos. So such possibility is null if we trust Kerberos.
b.) Other users on the system using the machine credential? It is not possible as
rpc.gssd allow this privilege to use machine credential to only uid=0(root). Even this can
be controlled by "/etc/nfs.conf", option use-machine-creds.
So in summary, this needs to be fix in ganehsa and there is no current comparable code
that matches with this in KNFSD as they are using different methods for it.
-pushpesh
On 20/01/20, 7:55 PM, "Daniel Gryniewicz" <dgryniew(a)redhat.com>
wrote:
I'm sorry, I'm very far from an expert in GSS/krb5. In particular,
I've
never used NFS and gssd together, so I have no personal experience.
Maybe someone else on the list can help?
For questions like this, our default has been "what does knfsd do?" Do
you happen to know if knfsd accepts "shorthostname(a)REALM.COM" as a root
user?
Daniel
On 1/18/20 11:50 PM, Pushpesh Sharma wrote:
Hi All,
Any pointers are appreciated..
-pushpesh
*From:* Pushpesh Sharma <pushpeshs(a)vmware.com>
*Sent:* Thursday, January 16, 2020 7:45 PM
*To:* devel(a)lists.nfs-ganesha.org
*Subject:* [NFS-Ganesha-Devel] Default KRB Principal name with new
rpc.gssd
Hi All,
We are trying to use ganehsa with KRB. On NFS client centos7.5 we are
joining Active Directory based using sssd(AD based KRB Realm). For
root user we are getting krb ticket using kinit and valid AD user.
Client principal while joining domain using sssd a default principal
of shorthostname$(a)REALM.COM <mailto:shorthostname$@REALM.COM> is
always generated. gss.rpcd by default send this principal as principal
user name to ganesha server. Client do have other principal like
nfs/client_fdqn(a)REALM.COM <mailto:nfs/client_fdqn@REALM.COM>. But as
per rpc.gssd documentation <mailto:rpc.gssd%20documentation> as well
first choice would be shorthostname$(a)REALM.COM
<mailto:shorthostname$@REALM.COM>.
Due to this server always recognize root user as someone else i.e.
shorthostname$(a)REALM.COM <mailto:shorthostname$@REALM.COM>.
We do see in src/idmapper/idmapper.c
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub....
handling for mapping three principal patterns nfs/* , root/*, host/*
to uid=0, gid=0. So this left shorthostname$(a)REALM.COM
<mailto:horthostname$@REALM.COM> principal not being recognized as root.
We are of the opinion that doing a small fix in above idmapper code to
add this pattern as well can fix this issue.
But we wanted to know any security concern around it? Or if the client
behavior can be change in any way, so we don’t need this fix?
If we try removing this shorthostname$(a)REALM.COM
<mailto:shorthostname$@REALM.COM>principal after domain join, sssd
cannot be re-loaded and complains about not finding this principal.
Thanks
-pushpesh
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
1766
days inactive
1796
days old
2 comments
2 participants
participants (2)
-
Daniel Gryniewicz -
Pushpesh Sharma