tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: inetd(8): cmdif as builtin
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.
Home |
Main Index |
Thread Index |
Old Index