Re: inetd(8): security behavior

On Mon, 29 May 2023 at 09:16, <[email protected]> wrote:
>
> I have sent another message, about inetd, to tech-userlevel for a more
> limited scope (correction of bugs about not handling realpath(3) return
> status) but there are more problems, IMHO, from a security standpoint in
> inetd (the current status; I seem to remember that there was a proposal
> to change the configuration processing; is this the result?).
>
> The security question: config() doesn't return a status (so caller
> has no information about errors) and merges any directive until it
> perhaps choke on an error, but not undoing all the directives coming
> from a faulty config file and neither exiting on error.
>
> I'm a bit unconfortable about this behavior: is this possible
> that someone starts by allowing things globally and then, lately,
> in the file, disable some particular points, and the disabling is
> never made because the parsing choked on a previous line?
>
> What do you think?

NetBSD tends to be more aware of historic behaviour than some other
projects, but I think this is the intersection of "behaviour is just
what came about" with "little used service, so has had less
attention".

I think having an option to abort on error, and/or validate the file
before actioning would be a good change (On balance I would probably
not include an option to disable it to get the current behaviour,
unless someone can pipe up with a good use case for that)

David