[kea-dev] kea-ctrl-agent on unix socket

[Francis Dupont]

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 <fdupont at isc.org>

PS: these are personal ideas. Perhaps my colleagues will have better proposals.