Re: inetd(8): security behavior

[tlaronde%polynum.com@localhost]

Le Mon, May 29, 2023 at 11:50:30AM +0100, David Brownlee a écrit :
> On Mon, 29 May 2023 at 09:16, <tlaronde%polynum.com@localhost> 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)
> 

Yes, and for a sake of consistency, I will add what I have added to the
discussion on tech-userlevel:

But I will once more plead for exit on error due to this feature (from
the man page):

---8<---
To avoid the need to repeat listen addresses over and over again, listen
addresses are inherited from line to line, and the listen address
can be changed without defining a service by including a line containing
just a listen-addr followed by a colon.
--->8---

If one such line fails, all that will be parsed after (necessarily from
another file) will potentially not listen where it should!

Imagine what it can be if telnet is listening on 22!

(One solution: clear the definition of the default address
parse.c/defhost when including another file.)

Since I will add, also, a flag for checking the syntax without running,
this should be no problem to exit on error: administrator has to test
his config before running (perhaps a semantically stupid config, but at
least syntactically correct one, doing what he has asked for).
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C