We have kerberos everywhere, and use it for access to NFS home directories.
So what do we do about cron jobs? We have a solution, but it involves custom code that impersonates the KDC. I’d like to do someone more standard.
Constained delegation seems like a possibility. But I’d need to be able to say “allow cron to get credentials for NFS for a specific group of users.” Since all of our systems run cron, I don’t want to allow any system to be able to get an NFS credential for any user. That would let root on any system see anyone’s files. So the user has to authorize it. Presumably if the user runs his own desktop, he’s willing to allow it to get credentials for himself. But I wouldn’t trust his machine to be able to get mine.
The constrained delegation mechanism seems to handle this, except that I don’t see a way to constrain it to specific users. Am I missing something?
Hi Charles,
please accept the following as quoted properly, as I am not allowed to use an email client to handle my email ;)
We have kerberos everywhere, and use it for access to NFS home directories.
So what do we do about cron jobs? We have a solution, but it involves custom code that impersonates the KDC. I’d like to do someone more standard. Constained delegation seems like a possibility. But I’d need to be able to say “allow cron to get credentials for NFS for a specific group of users.” Since all of our systems run cron, I don’t want to allow any system to be able to get an NFS credential for any user. That would let root on any system see anyone’s files. So the user has to authorize it. Presumably if the user runs his own desktop, he’s willing to allow it to get credentials for himself. But I wouldn’t trust his machine to be able to get mine.
Considering the following:
[nfs share machines] <=> [cron running machines]
You may store keytab files on the cron machines to be able to auth as the user and use NFS. The keytabs may be stored to the cron host for the specific, if you have cron hosts this is complicated.
The constrained delegation mechanism seems to handle this, except that I don’t see a way to constrain it to specific users. Am I missing something?
You may think of a shadow user for each user( like a evil twin - taking nfs into account ;) ), which share the same groups, but can be restricted in terms of how to use it's rights via privileges in the ipa. So it's able to use the scope you need for the cron scripts. With a keytab of this bad boy it would be possible to mount the same resource without having the risk that this creds are use to abuse other parts of your infrastrucure.
There also would be the alternative to use certificates for that exact purpose. You may think of representing the NFS stored data differently. For example as a http(s) using nginx or apache. There you have a wide range of options to auth a request and may can mal this accordingly and more precise.
allow cron to get credentials for NFS for a specific group of users.
You also can go with what sun did, ages ago. You mount it with host credentials and then use the std unix user permissions in the file system to grant for block access to parts of the mounted tree. Problematic is that your services or hosts may get stuck, because the nfs server dies.
Another idea would be to use sshfs (fuse) and ssh public keys. Cron would be able to mount the environment, if you can provide wrapper script for your user base. With that this would be flawless. Positive would be that ssh keys could be limited to allow configured and by that allowed interactions (like sftp only or such).
Generally I would recommend to not have cron running under user control. It's a quest and challenge to find them back, when an user disappears forever. But back to topic...
The problem is as you already stated, that you can impersonate without limitations when using the users keytab or similar, which may lead into a bigger problem.
Regards, Sven _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste...
On ma, 21 loka 2019, Charles Hedrick via FreeIPA-users wrote:
We have kerberos everywhere, and use it for access to NFS home directories.
So what do we do about cron jobs? We have a solution, but it involves custom code that impersonates the KDC. I’d like to do someone more standard.
Constained delegation seems like a possibility. But I’d need to be able to say “allow cron to get credentials for NFS for a specific group of users.” Since all of our systems run cron, I don’t want to allow any system to be able to get an NFS credential for any user. That would let root on any system see anyone’s files. So the user has to authorize it. Presumably if the user runs his own desktop, he’s willing to allow it to get credentials for himself. But I wouldn’t trust his machine to be able to get mine.
The constrained delegation mechanism seems to handle this, except that I don’t see a way to constrain it to specific users. Am I missing something?
There are two parts here: S4U2Self and S4U2Proxy. The former is for allowing protocol transition: a service can claim that it has authenticated the user some way beyond Kerberos and now want a service ticket to itself from that user. Once the service has a ticket to itself, S4U2Proxy can be used to operate on behalf of that user against another service. The right to allow it is on the KDC side and in FreeIPA we use it, for example, to operate on behalf of a user when managing IPA itself (IPA management framework runs in Apache and talks to LDAP and Samba with SASL GSS-SPNEGO).
We don't have nice tools to enable constraint delegation in an easy way (and there is no templating) but you can look at https://pagure.io/freeipa/blob/master/f/daemons/ipa-kdb/README.s4u2proxy.txt and https://pagure.io/freeipa/blob/master/f/install/share/bootstrap-template.ldi... (until line 221)
Also, you don't need to use kadmin.local as in the README document, it is now possible to change Kerberos flags through 'ipa service-mod'.
In cron environment you don't have user's credentials or existing TGT. So you'd use S4U2Self as a 'cron' service to request one. You may want to protect access to 'cron' service credentials with GSS-Proxy and use keytab-based initialization there, also allowing both protocol transition and constrained delegation.
However, something needs to perform S4U2Self first. The document above mentions use of kinit/kvno tools. However, these tools are raw Kerberos, they do not support using GSS-Proxy. You need something that uses GSSAPI, not low-level Kerberos APIs. For example, python-gssapi could be used to build a simple app or you might write GSSAPI application in C, similar to https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u2proxy_krb5.c and https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u.c
Thanks. This is what I’m looking to do. The main question was doing it only for some users. The IPA commands to set it up, and the documentation, don’t show any way to limit delegation to specific users. But the text file describes an additional attribute. It is described one place as not implemented, but I looked at the IPA source, and it looks like it is implemented. I’ll try this. If it works it would be a significant improvement for us.
On Oct 22, 2019, at 6:22 AM, Alexander Bokovoy abokovoy@redhat.com wrote:
On ma, 21 loka 2019, Charles Hedrick via FreeIPA-users wrote:
We have kerberos everywhere, and use it for access to NFS home directories.
So what do we do about cron jobs? We have a solution, but it involves custom code that impersonates the KDC. I’d like to do someone more standard.
Constained delegation seems like a possibility. But I’d need to be able to say “allow cron to get credentials for NFS for a specific group of users.” Since all of our systems run cron, I don’t want to allow any system to be able to get an NFS credential for any user. That would let root on any system see anyone’s files. So the user has to authorize it. Presumably if the user runs his own desktop, he’s willing to allow it to get credentials for himself. But I wouldn’t trust his machine to be able to get mine.
The constrained delegation mechanism seems to handle this, except that I don’t see a way to constrain it to specific users. Am I missing something?
There are two parts here: S4U2Self and S4U2Proxy. The former is for allowing protocol transition: a service can claim that it has authenticated the user some way beyond Kerberos and now want a service ticket to itself from that user. Once the service has a ticket to itself, S4U2Proxy can be used to operate on behalf of that user against another service. The right to allow it is on the KDC side and in FreeIPA we use it, for example, to operate on behalf of a user when managing IPA itself (IPA management framework runs in Apache and talks to LDAP and Samba with SASL GSS-SPNEGO).
We don't have nice tools to enable constraint delegation in an easy way (and there is no templating) but you can look at https://pagure.io/freeipa/blob/master/f/daemons/ipa-kdb/README.s4u2proxy.txt and https://pagure.io/freeipa/blob/master/f/install/share/bootstrap-template.ldi... (until line 221)
Also, you don't need to use kadmin.local as in the README document, it is now possible to change Kerberos flags through 'ipa service-mod'.
In cron environment you don't have user's credentials or existing TGT. So you'd use S4U2Self as a 'cron' service to request one. You may want to protect access to 'cron' service credentials with GSS-Proxy and use keytab-based initialization there, also allowing both protocol transition and constrained delegation. However, something needs to perform S4U2Self first. The document above mentions use of kinit/kvno tools. However, these tools are raw Kerberos, they do not support using GSS-Proxy. You need something that uses GSSAPI, not low-level Kerberos APIs. For example, python-gssapi could be used to build a simple app or you might write GSSAPI application in C, similar to https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u2proxy_krb5.c and https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u.c
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
On ti, 22 loka 2019, Charles Hedrick wrote:
Thanks. This is what I’m looking to do. The main question was doing it only for some users. The IPA commands to set it up, and the documentation, don’t show any way to limit delegation to specific users. But the text file describes an additional attribute. It is described one place as not implemented, but I looked at the IPA source, and it looks like it is implemented. I’ll try this. If it works it would be a significant improvement for us.
Yes. Please share your findings, even if negative. Perhaps, we would need to add something to support his case. At least, ipaAllowToImpersonate needs to be added into IPA framework to allow manage it.
On Oct 22, 2019, at 6:22 AM, Alexander Bokovoy abokovoy@redhat.com wrote:
On ma, 21 loka 2019, Charles Hedrick via FreeIPA-users wrote:
We have kerberos everywhere, and use it for access to NFS home directories.
So what do we do about cron jobs? We have a solution, but it involves custom code that impersonates the KDC. I’d like to do someone more standard.
Constained delegation seems like a possibility. But I’d need to be able to say “allow cron to get credentials for NFS for a specific group of users.” Since all of our systems run cron, I don’t want to allow any system to be able to get an NFS credential for any user. That would let root on any system see anyone’s files. So the user has to authorize it. Presumably if the user runs his own desktop, he’s willing to allow it to get credentials for himself. But I wouldn’t trust his machine to be able to get mine.
The constrained delegation mechanism seems to handle this, except that I don’t see a way to constrain it to specific users. Am I missing something?
There are two parts here: S4U2Self and S4U2Proxy. The former is for allowing protocol transition: a service can claim that it has authenticated the user some way beyond Kerberos and now want a service ticket to itself from that user. Once the service has a ticket to itself, S4U2Proxy can be used to operate on behalf of that user against another service. The right to allow it is on the KDC side and in FreeIPA we use it, for example, to operate on behalf of a user when managing IPA itself (IPA management framework runs in Apache and talks to LDAP and Samba with SASL GSS-SPNEGO).
We don't have nice tools to enable constraint delegation in an easy way (and there is no templating) but you can look at https://pagure.io/freeipa/blob/master/f/daemons/ipa-kdb/README.s4u2proxy.txt and https://pagure.io/freeipa/blob/master/f/install/share/bootstrap-template.ldi... (until line 221)
Also, you don't need to use kadmin.local as in the README document, it is now possible to change Kerberos flags through 'ipa service-mod'.
In cron environment you don't have user's credentials or existing TGT. So you'd use S4U2Self as a 'cron' service to request one. You may want to protect access to 'cron' service credentials with GSS-Proxy and use keytab-based initialization there, also allowing both protocol transition and constrained delegation. However, something needs to perform S4U2Self first. The document above mentions use of kinit/kvno tools. However, these tools are raw Kerberos, they do not support using GSS-Proxy. You need something that uses GSSAPI, not low-level Kerberos APIs. For example, python-gssapi could be used to build a simple app or you might write GSSAPI application in C, similar to https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u2proxy_krb5.c and https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u.c
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
I just realized a problem with the whole scheme. Our situation may be unusual, but we have machines run by users. They can become root. Linux is also not provably secure, so I have to worry about it even on systems we administer.
Schemes based on constrained delegation have to start with a service that is authorized to get credentials. It’s hard to see any way of doing the original service authentication other than a key table. But key tables can be stolen by root and used anywhere. Is there any way to get IPA to refuse to grant credentials for service/HOST except if the request comes from HOST? I know IP addresses aren’t perfect, but our subnets have machines with similar security properties, and our switches prevent people from sending packets with a source address off their subnet. So IP restrictions are actually worthwhile.
Our current scheme uses a daemon that implements what is effectively constrained delegation. Users register that they want to run cron jobs on a specific host. We have a pam module used when cron starts are job. It talks to the daemon, and gets back a ticket for the user, if the user has authorized it. The daemon won’t return a ticket unless the request comes from root on a host that the user has authorized. The tickets returned by the daemon have the IP address set, and the forward bit off, so they’re as constrained as I can make them. It could be that we should actually return just an NFS service ticket rather than a TGT.
On Oct 22, 2019, at 7:18:58 AM, Alexander Bokovoy abokovoy@redhat.com wrote:
On ti, 22 loka 2019, Charles Hedrick wrote:
Thanks. This is what I’m looking to do. The main question was doing it only for some users. The IPA commands to set it up, and the documentation, don’t show any way to limit delegation to specific users. But the text file describes an additional attribute. It is described one place as not implemented, but I looked at the IPA source, and it looks like it is implemented. I’ll try this. If it works it would be a significant improvement for us.
Yes. Please share your findings, even if negative. Perhaps, we would need to add something to support his case. At least, ipaAllowToImpersonate needs to be added into IPA framework to allow manage it.
On Oct 22, 2019, at 6:22 AM, Alexander Bokovoy abokovoy@redhat.com wrote:
On ma, 21 loka 2019, Charles Hedrick via FreeIPA-users wrote:
We have kerberos everywhere, and use it for access to NFS home directories.
So what do we do about cron jobs? We have a solution, but it involves custom code that impersonates the KDC. I’d like to do someone more standard.
Constained delegation seems like a possibility. But I’d need to be able to say “allow cron to get credentials for NFS for a specific group of users.” Since all of our systems run cron, I don’t want to allow any system to be able to get an NFS credential for any user. That would let root on any system see anyone’s files. So the user has to authorize it. Presumably if the user runs his own desktop, he’s willing to allow it to get credentials for himself. But I wouldn’t trust his machine to be able to get mine.
The constrained delegation mechanism seems to handle this, except that I don’t see a way to constrain it to specific users. Am I missing something?
There are two parts here: S4U2Self and S4U2Proxy. The former is for allowing protocol transition: a service can claim that it has authenticated the user some way beyond Kerberos and now want a service ticket to itself from that user. Once the service has a ticket to itself, S4U2Proxy can be used to operate on behalf of that user against another service. The right to allow it is on the KDC side and in FreeIPA we use it, for example, to operate on behalf of a user when managing IPA itself (IPA management framework runs in Apache and talks to LDAP and Samba with SASL GSS-SPNEGO).
We don't have nice tools to enable constraint delegation in an easy way (and there is no templating) but you can look at https://pagure.io/freeipa/blob/master/f/daemons/ipa-kdb/README.s4u2proxy.txt and https://pagure.io/freeipa/blob/master/f/install/share/bootstrap-template.ldi... (until line 221)
Also, you don't need to use kadmin.local as in the README document, it is now possible to change Kerberos flags through 'ipa service-mod'.
In cron environment you don't have user's credentials or existing TGT. So you'd use S4U2Self as a 'cron' service to request one. You may want to protect access to 'cron' service credentials with GSS-Proxy and use keytab-based initialization there, also allowing both protocol transition and constrained delegation. However, something needs to perform S4U2Self first. The document above mentions use of kinit/kvno tools. However, these tools are raw Kerberos, they do not support using GSS-Proxy. You need something that uses GSSAPI, not low-level Kerberos APIs. For example, python-gssapi could be used to build a simple app or you might write GSSAPI application in C, similar to https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u2proxy_krb5.c and https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u.c
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
On ti, 22 loka 2019, Charles Hedrick wrote:
I just realized a problem with the whole scheme. Our situation may be unusual, but we have machines run by users. They can become root. Linux is also not provably secure, so I have to worry about it even on systems we administer.
Schemes based on constrained delegation have to start with a service that is authorized to get credentials. It’s hard to see any way of doing the original service authentication other than a key table. But key tables can be stolen by root and used anywhere. Is there any way to get IPA to refuse to grant credentials for service/HOST except if the request comes from HOST? I know IP addresses aren’t perfect, but our subnets have machines with similar security properties, and our switches prevent people from sending packets with a source address off their subnet. So IP restrictions are actually worthwhile.
No, this is not possible right now with current FreeIPA.
With MIT Kerberos 1.17 there is a plugin interface to hook into KDC policy decision making at both AS-REQ and TGS-REQ. Also, since 1.16 we could use addresses of the client and KDC to allow or deny AS request. But this is not implemented in FreeIPA.
Since IP addresses are practically spoofable or NATable, they don't make a good source of policy decision.
I'm not really sure there will be any work on implementing something like this but we are working on KDC policy extensions already.
Our current scheme uses a daemon that implements what is effectively constrained delegation. Users register that they want to run cron jobs on a specific host. We have a pam module used when cron starts are job. It talks to the daemon, and gets back a ticket for the user, if the user has authorized it. The daemon won’t return a ticket unless the request comes from root on a host that the user has authorized. The tickets returned by the daemon have the IP address set, and the forward bit off, so they’re as constrained as I can make them. It could be that we should actually return just an NFS service ticket rather than a TGT.
What we could have is a per-user list of services it is allowed to obtain a ticket to. But I don't think we could have it reverted in practice. Even if a user is able to obtain a ticket from machine A, it doesn't mean it is not able to use it from machine B.
On Oct 22, 2019, at 7:18:58 AM, Alexander Bokovoy abokovoy@redhat.com wrote:
On ti, 22 loka 2019, Charles Hedrick wrote:
Thanks. This is what I’m looking to do. The main question was doing it only for some users. The IPA commands to set it up, and the documentation, don’t show any way to limit delegation to specific users. But the text file describes an additional attribute. It is described one place as not implemented, but I looked at the IPA source, and it looks like it is implemented. I’ll try this. If it works it would be a significant improvement for us.
Yes. Please share your findings, even if negative. Perhaps, we would need to add something to support his case. At least, ipaAllowToImpersonate needs to be added into IPA framework to allow manage it.
On Oct 22, 2019, at 6:22 AM, Alexander Bokovoy abokovoy@redhat.com wrote:
On ma, 21 loka 2019, Charles Hedrick via FreeIPA-users wrote:
We have kerberos everywhere, and use it for access to NFS home directories.
So what do we do about cron jobs? We have a solution, but it involves custom code that impersonates the KDC. I’d like to do someone more standard.
Constained delegation seems like a possibility. But I’d need to be able to say “allow cron to get credentials for NFS for a specific group of users.” Since all of our systems run cron, I don’t want to allow any system to be able to get an NFS credential for any user. That would let root on any system see anyone’s files. So the user has to authorize it. Presumably if the user runs his own desktop, he’s willing to allow it to get credentials for himself. But I wouldn’t trust his machine to be able to get mine.
The constrained delegation mechanism seems to handle this, except that I don’t see a way to constrain it to specific users. Am I missing something?
There are two parts here: S4U2Self and S4U2Proxy. The former is for allowing protocol transition: a service can claim that it has authenticated the user some way beyond Kerberos and now want a service ticket to itself from that user. Once the service has a ticket to itself, S4U2Proxy can be used to operate on behalf of that user against another service. The right to allow it is on the KDC side and in FreeIPA we use it, for example, to operate on behalf of a user when managing IPA itself (IPA management framework runs in Apache and talks to LDAP and Samba with SASL GSS-SPNEGO).
We don't have nice tools to enable constraint delegation in an easy way (and there is no templating) but you can look at https://pagure.io/freeipa/blob/master/f/daemons/ipa-kdb/README.s4u2proxy.txt and https://pagure.io/freeipa/blob/master/f/install/share/bootstrap-template.ldi... (until line 221)
Also, you don't need to use kadmin.local as in the README document, it is now possible to change Kerberos flags through 'ipa service-mod'.
In cron environment you don't have user's credentials or existing TGT. So you'd use S4U2Self as a 'cron' service to request one. You may want to protect access to 'cron' service credentials with GSS-Proxy and use keytab-based initialization there, also allowing both protocol transition and constrained delegation. However, something needs to perform S4U2Self first. The document above mentions use of kinit/kvno tools. However, these tools are raw Kerberos, they do not support using GSS-Proxy. You need something that uses GSSAPI, not low-level Kerberos APIs. For example, python-gssapi could be used to build a simple app or you might write GSSAPI application in C, similar to https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u2proxy_krb5.c and https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u.c
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
within a department it’s actually pretty good, as long as you know the limitations. I wouldn’t use it as my only security, but it’s a useful supplement to checking a key table.
On Oct 22, 2019, at 9:40 AM, Alexander Bokovoy <abokovoy@redhat.commailto:abokovoy@redhat.com> wrote:
Since IP addresses are practically spoofable or NATable, they don't make a good source of policy decision.
On ti, 22 loka 2019, Charles Hedrick wrote:
within a department it’s actually pretty good, as long as you know the limitations. I wouldn’t use it as my only security, but it’s a useful supplement to checking a key table.
You already can write an ebpf filter that would reject AS-REQ requests from incorrect locations.
In a quick internal discussion with Simo and Robbie (Kerberos maintainer) we came to a common conclusion we don't want to have this supported in MIT Kerberos/FreeIPA.
On Oct 22, 2019, at 9:40 AM, Alexander Bokovoy <abokovoy@redhat.commailto:abokovoy@redhat.com> wrote:
Since IP addresses are practically spoofable or NATable, they don't make a good source of policy decision.
ok. So delegation works. Now we come to the question of how to configure it in gssproxy. The man page describes the syntax of the file but not how it actually works. Any suggestions?
On Oct 22, 2019, at 9:52 AM, Alexander Bokovoy abokovoy@redhat.com wrote:
On ti, 22 loka 2019, Charles Hedrick wrote:
within a department it’s actually pretty good, as long as you know the limitations. I wouldn’t use it as my only security, but it’s a useful supplement to checking a key table.
You already can write an ebpf filter that would reject AS-REQ requests from incorrect locations.
In a quick internal discussion with Simo and Robbie (Kerberos maintainer) we came to a common conclusion we don't want to have this supported in MIT Kerberos/FreeIPA.
On Oct 22, 2019, at 9:40 AM, Alexander Bokovoy <abokovoy@redhat.commailto:abokovoy@redhat.com> wrote:
Since IP addresses are practically spoofable or NATable, they don't make a good source of policy decision.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
On ti, 22 loka 2019, Charles Hedrick via FreeIPA-users wrote:
ok. So delegation works. Now we come to the question of how to configure it in gssproxy. The man page describes the syntax of the file but not how it actually works. Any suggestions?
That is something for Simo, as gssproxy upstream. Unfortunately, I have no time right now to investigate that.
May be you can file a ticket to gssproxy asking to document that?
On Tue, 2019-10-22 at 18:43 +0300, Alexander Bokovoy via FreeIPA-users wrote:
On ti, 22 loka 2019, Charles Hedrick via FreeIPA-users wrote:
ok. So delegation works. Now we come to the question of how to configure it in gssproxy. The man page describes the syntax of the file but not how it actually works. Any suggestions?
That is something for Simo, as gssproxy upstream. Unfortunately, I have no time right now to investigate that.
May be you can file a ticket to gssproxy asking to document that?
What's the ask exactly ?
On Tue, 2019-10-22 at 14:31 -0400, Simo Sorce via FreeIPA-users wrote:
On Tue, 2019-10-22 at 18:43 +0300, Alexander Bokovoy via FreeIPA-users wrote:
On ti, 22 loka 2019, Charles Hedrick via FreeIPA-users wrote:
ok. So delegation works. Now we come to the question of how to configure it in gssproxy. The man page describes the syntax of the file but not how it actually works. Any suggestions?
That is something for Simo, as gssproxy upstream. Unfortunately, I have no time right now to investigate that.
May be you can file a ticket to gssproxy asking to document that?
What's the ask exactly ?
If it is NFS related please read this first: https://pagure.io/gssproxy/blob/master/f/docs/NFS.md
-- Simo Sorce RHEL Crypto Team Red Hat, Inc
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste...
On ti, 22 loka 2019, Simo Sorce via FreeIPA-users wrote:
On Tue, 2019-10-22 at 14:31 -0400, Simo Sorce via FreeIPA-users wrote:
On Tue, 2019-10-22 at 18:43 +0300, Alexander Bokovoy via FreeIPA-users wrote:
On ti, 22 loka 2019, Charles Hedrick via FreeIPA-users wrote:
ok. So delegation works. Now we come to the question of how to configure it in gssproxy. The man page describes the syntax of the file but not how it actually works. Any suggestions?
That is something for Simo, as gssproxy upstream. Unfortunately, I have no time right now to investigate that.
May be you can file a ticket to gssproxy asking to document that?
What's the ask exactly ?
If it is NFS related please read this first: https://pagure.io/gssproxy/blob/master/f/docs/NFS.md
Right, 'impersonate = true' covers both steps. Thanks!
yes, this is what I tried. It does work, as I noted before. I believe the restriction to specific users also works.
On Oct 22, 2019, at 3:05 PM, Alexander Bokovoy abokovoy@redhat.com wrote:
On ti, 22 loka 2019, Simo Sorce via FreeIPA-users wrote:
On Tue, 2019-10-22 at 14:31 -0400, Simo Sorce via FreeIPA-users wrote:
On Tue, 2019-10-22 at 18:43 +0300, Alexander Bokovoy via FreeIPA-users wrote:
On ti, 22 loka 2019, Charles Hedrick via FreeIPA-users wrote:
ok. So delegation works. Now we come to the question of how to configure it in gssproxy. The man page describes the syntax of the file but not how it actually works. Any suggestions?
That is something for Simo, as gssproxy upstream. Unfortunately, I have no time right now to investigate that.
May be you can file a ticket to gssproxy asking to document that?
What's the ask exactly ?
If it is NFS related please read this first: https://pagure.io/gssproxy/blob/master/f/docs/NFS.md
Right, 'impersonate = true' covers both steps. Thanks!
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
I have something working. It may be enough.
In principle there’s a two-stage process, with cron getting a ticket from s4u2self, and then using s4u2proxy get the final nfs credentials. If that worked, gssproxy would only be able to get an NFS credential if there’s actually a cron job for the user. because the first step would be done by cron only at the start of a cron job.
At the moment it doesn’t appear that I can give gssproxy a credential cache with the tickets from s4u2self. However I can configure gssproxy to read cron’s key table itself, and thus do both steps of the impersonation. That works just fine. What it means is that users who use cron jobs will be able to access NFS at any time, not just from the cron jobs. But it’s not clear how much difference there is in practice. Root can of course su to any user. But root can also create a cron job for any user, so requiring there to be a cron job doesn’t give any additional real protection.
I did verify that ipaAllowToImpersonate works. I would definitely prefer a way to do that through IPA commands.
This looks like a better approach than the daemon I’m currently using.
On Oct 22, 2019, at 11:43 AM, Alexander Bokovoy abokovoy@redhat.com wrote:
On ti, 22 loka 2019, Charles Hedrick via FreeIPA-users wrote:
ok. So delegation works. Now we come to the question of how to configure it in gssproxy. The man page describes the syntax of the file but not how it actually works. Any suggestions?
That is something for Simo, as gssproxy upstream. Unfortunately, I have no time right now to investigate that.
May be you can file a ticket to gssproxy asking to document that?
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
The kdc doesn’t supply the remote address to the policy plugin, unless I’m totally misreading the source code. I’m currently investigating ways of doing it externally, whether ebpf or something else.
On Oct 22, 2019, at 9:40 AM, Alexander Bokovoy <abokovoy@redhat.commailto:abokovoy@redhat.com> wrote:
I'm not really sure there will be any work on implementing something like this but we are working on KDC policy extensions already.
On ke, 23 loka 2019, Charles Hedrick wrote:
The kdc doesn’t supply the remote address to the policy plugin, unless I’m totally misreading the source code. I’m currently investigating ways of doing it externally, whether ebpf or something else.
Ok.
The interface (krb5_kdc_req struct) still has addresses there but they might not be filled in. The krb5_kdc_req struct is supplied to the policy plugin.
On Oct 22, 2019, at 9:40 AM, Alexander Bokovoy <abokovoy@redhat.commailto:abokovoy@redhat.com> wrote:
I'm not really sure there will be any work on implementing something like this but we are working on KDC policy extensions already.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Charles Hedrick -
Simo Sorce -
Sven Ludwig