Re: inetd(8): cmdif as builtin

[Luke Mewburn <luke%mewburn.net@localhost>]

On 23-06-13 07:45, Brett Lymn wrote:
  | On Fri, Jun 09, 2023 at 08:47:10AM -0400, Mouse wrote:
  | > 
  | > In any case, the major issue I would have with it is the lack of
  | > authentication.  But that's so obvious that I assume you would be doing
  | > something like requiring a password - or doing it only for AF_LOCAL
  | > sockets and using LOCAL_PEEREID.  (This is pretty close to what most of
  | > my pidconn servers do - they use the pidconn analog of LOCAL_PEEREID to
  | > verify that the client is either root or the same UID the server is
  | > running as.)
  | > 
  | 
  | When this was done in last years GSoC it was a AF_LOCAL socket to
  | control inetd.  I am not sure that inetd having a configuration service
  | listening on the network is a really good idea - to me, it sounds
  | dangerous and I am dubious that there are many situations that require
  | remote configuration of inetd.

I agree.

If you keep it to AF_UNIX, then you can enforce LOCAL_PEEREID (or
SO_PEERCRED or equivalent) checking to ensure that the peer is an
appropriate local UID (or GID). You could even have different tiers of
control, such as "group X for query status" (e.g., for remote monitoring
apps that connect in via SSH or whatever), versus "group Y for admin
privs to change status", although that's scope creeping...

This reduces the remote attack surface to your operations and management
(OAM) / MANO / ... systems. If you need "remote" management, solve it
like we do for a lot of other systems and remote in (i.e, ssh) to run as
a local user, with the existing remote access controls for that.