On Пят, 15 ліс 2024, Magnus Sandberg via FreeIPA-users wrote:
Alexander Bokovoy wrote:
On Пят, 15 ліс 2024, Magnus Sandberg via FreeIPA-users wrote:
> 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.
First of all, thanks for spending time answering my questions.
If I understand you correct the KDC policy sees the remote address the
client uses in the connection to the KDC, if using IP protocols.
Wouldn't that be enough to create the policy I'm thinking of? Also
accepting the upcoming local UNIX socket.
It is the other way around. KDC policy plugin doesn't get access to the
remote address the client actually used, only to the list of addresses
it might have presented to the KDC as a part of the request. So it
cannot decide based on where the request came from.
--
/ 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
