On Пят, 15 ліс 2024, Magnus Sandberg via FreeIPA-users wrote:
Alexander Bokovoy wrote:
On Чцв, 14 ліс 2024, Magnus Sandberg via FreeIPA-users wrote:
> Hi,
> This is a rather late reply but I'm now to RedHat IdM.
> Would it be possible to have a kdcpolicy plugin that only allow admin
> tokens issued on machines that are listed in some allow list? I guess
> the list could even by dynamic as I also would like to limit it to the
> IdM servers them selves.
It is possible to write a KDC policy plugin but I don't think it will
help. Kerberos tickets have concept of adressfulness but it is not used
in real life due to NATs and other factors.
See, for example, very recent discussion upstream where MIT Kerberos
upstream maintainer explains it:
https://github.com/krb5/krb5/pull/1359#issuecomment-2472625591
--------
Addressful tickets are rarely used. When they are used, the AS client
decides what addresses get stored in the ticket. The ticket is then
restricted to use from one of the listed addresses. In our client
implementation (e.g. if you do "kinit -a"), we construct a list of the
local interface IP addresses and asks for those.
---------
So if you want to make decision based on the addresses client has provided in
the list, you are already in a pretty bad situation as you have to trust
that information. What if an attacker knows that you will only be
issuing 'admin' tickets on IPA servers? They'd simply fabricate their
AS-REQ packet with corresponding addresses.
A better approach would be to switch admin accounts to use passwordless
authentication methods, with factors that cannot be easily get access to
by attackers: smartcards or FIDO2 passkeys, for example.
Thanks for your reply. I'm not familiar with the krb source code and
what's going on internally but I think I got some understanding about
the ongoing work from the link you provided.
My usecase it to "help" my fellow IdM admins to not manage the IdM from
the wrong machine. Our policy states that you should manage the IdM
locally via dedicated jumphosts. But when you're in a hurry to fix a
problem it may be easy to do "kinit admin" and use the relevant ipa
commands from some host just to fix the problem, and that wouldn't be
okay. As this is for internal use in our own networks, we don't have
NAT between our networks. And the main goal is not to protect against
an attacker.
I checked KDC source code. There are two sets of addresses we know about
during ticket issuance:
- the remote address a client used to establish connection to us. It
might be IPv4, IPv6, or something else (it will be UNIX domain socket
in case of a local KDC, for example).
- the set of addresses the client puts into a ticket request. These
will be used to check against the client's address in case of
addressful tickets.
KDC policy plugin does have access to the former but not to the latter.
It means KDC policy plugin cannot say 'this client address as seen by
KDC cannot request this ticket'. It can only say 'this client address in
the client request is OK or not OK for a request'.
There is another plugin type: audit plugin. This one gets all
information and is called early in the processing stage, so technically
it could decide whether a particular request is allowed or not based on
the client remote address. There are two issues, though:
- audit plugin calls cannot influence control flow; AS-REQ audit does
not return a state that could be processed to stop a ticket issuance;
- audit plugin call for AS-REQ happens *before* we parsed the original
request, so the data was not yet validated.
So either plugin is not capable to handle this case.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
