[prev in list] [next in list] [prev in thread] [next in thread]
List: netbsd-tech-userlevel
Subject: Re: inetd(8): cmdif as builtin
From: Luke Mewburn <luke () mewburn ! net>
Date: 2023-06-15 21:11:59
Message-ID: ZIt+nwAn1ErMy88F () mewburn ! net
[Download RAW message or body]
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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic