3:21 p.m.
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?
4:15 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
5:22 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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....
(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
6:05 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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(a)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....
(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
6:18 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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(a)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....
> (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
7:54 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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(a)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(a)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....
>> (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
8:40 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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(a)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(a)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....
>>> (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
>
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
8:44 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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.com<mailto:abokovoy@redhat.com>> wrote:
Since IP addresses are practically spoofable or NATable, they don't make
a good source of policy decision.
8:52 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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.com<mailto: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
10:23 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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(a)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.com<mailto: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
10:43 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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
1:31 p.m.
New subject: is it possible to enable constrained delegation for only some users?
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 ?
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
1:34 p.m.
New subject: is it possible to enable constrained delegation for only some users?
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(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
2:05 p.m.
New subject: is it possible to enable constrained delegation for only some users?
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
8:23 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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(a)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
1:52 p.m.
New subject: is it possible to enable constrained delegation for only some users?
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(a)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
8:27 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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.com<mailto: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.
8:41 a.m.
New subject: is it possible to enable constrained delegation for only some users?
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.com<mailto: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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
1646
days inactive
1648
days old
freeipa-users@lists.fedorahosted.org
17 comments
4 participants
participants (4)
-
Alexander Bokovoy -
Charles Hedrick -
Simo Sorce -
Sven Ludwig