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 <aboko...@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 <aboko...@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.ldif#_200 >>> (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 > _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
