tech-security archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

inetd(8): security behavior



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


Home | Main Index | Thread Index | Old Index