Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. kea-ctrl-agent on unix socket (Andreas Hasenack)
----------------------------------------------------------------------
Message: 1
Date: Tue, 14 Mar 2023 09:57:20 -0300
From: Andreas Hasenack <[email protected]>
To: [email protected]
Subject: [kea-dev] kea-ctrl-agent on unix socket
Message-ID:
<CANYNYEHLXjRb==wooe6dqqcpu_ewny7mdgtxotrvskbescg...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
together with my colleagues I'm packaging isc-kea for Ubuntu, and
Debian as a consequence.
After using the software for a while, and writing tests for it, we
realized that once you install the kea-ctrl-agent, any unprivileged
local user has unrestricted API access and can do naughty things like
kill the service, read the config file (which might have passwords for
database backends), manage leases, etc.
I know one can add http basic auth to the service, or even not install
it of course. But I think it should be a bit more secure by default
out of the box, and still be usable.
We can create a random user/password at install time, but I was
wondering if you ever considered having kea-ctrl-agent listen on its
own unix socket, and have kea-shell use that? Controlling localhost
access would be much simpler: one could just chmod/chown the socket
appropriately and then the local admin of the system can decide who to
add to the group that can use the api locally.
What we are considering for now is to either not start the service by
default (kind of against the policy of debian packaging), or create a
user with a random password in postinst, use `password-file` and
`user-file` under authentication.clients, and document that behavior,
but maybe there is another simpler way that is being used out there?
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 83, Issue 1
**************************************
