Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > muc.lists.netbsd.tech.security > #229

inetd(8): security behavior

Show all headers | View raw

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?
-- 
        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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

Back to muc.lists.netbsd.tech.security | Previous | Next — Next in thread | Find similar

Thread

inetd(8): security behavior tlaronde@polynum.com - 2023-05-29 10:16 +0200
  Re: inetd(8): security behavior David Brownlee <abs@netbsd.org> - 2023-05-29 11:50 +0100
    Re: inetd(8): security behavior Martin Husemann <martin@duskware.de> - 2023-05-29 13:45 +0200

csiph-web