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. Re: kea-ctrl-agent on unix socket (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Wed, 15 Mar 2023 13:59:26 +0000
From: Francis Dupont <[email protected]>
To: Andreas Hasenack <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] kea-ctrl-agent on unix socket
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Andreas Hasenack writes:
> 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.
=> there are 3 answers to this issue (BTW if you have local users I am
afraid that when you can't trust them you are already in trouble but
as I am old enough to know the "department server" period I understand
you'd like to have this case securely handled:
- the first feature which is dedicated to this particular case is
the HTTP simple authentication
- you can too use HTTPS aka HTTP over TLS. It moves the issue to the
PKI configuration but covers larger cases
- you can use the RBAC hook library: it provides fine grain access control,
for instance you can allow only read operations to an user group.
> 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.
=> I propose to not enable the service by default.
> 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,
=> this does not make sense: if you want to use an UNIX socket you do not
need the control agent at all.
> 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.
=> yes, the access control for UNIX sockets is something both easy
and well understood by admins.
> What we are considering for now is to either not start the service by
> default (kind of against the policy of debian packaging),
=> IMHO it is the best: in most cases it is not required. You can also
use a configuration which makes it not usable e.g. not set the DHCP
server UNIX socket paths.
> 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?
Regards
Francis Dupont <[email protected]>
PS: these are personal ideas. Perhaps my colleagues will have better proposals.
------------------------------
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 2
**************************************
