Hi All, Some years ago (late '90s) I stopped using inetd, because there were some serious security issues. I think mainly around the portmapper, IIRC. Anyway, I moved to making all the services I want to use run as permanent daemons - exim, apache etc. etc. This has worked fine - I've not touched inetd since then. Until now - I've just installed Leafnode, having found Cnews way too abstruse and INN too big for my needs. Leafnode will not run as a standalone daemon, so I have had to reinstall inetd. I'm using the "openbsd-inetd" which comes with my distro (Debian Etch). I've been unable to find any up-to-date analysis of this version of inetd. All I can find are a few articles that say, basically "inetd used to be insecure, most people use xinetd now". Can anyone here enlighten me a little further? Am I running any particular security risks using the default Debian inetd? Should I switch to xinetd? Grateful for any tips, or pointers to articles etc. Many thanks, CC

"Magnate" <contact.me@some.other.way> writes: >Hi All, >Some years ago (late '90s) I stopped using inetd, because there were some >serious security issues. I think mainly around the portmapper, IIRC. Anyway, >I moved to making all the services I want to use run as permanent daemons - >exim, apache etc. etc. >This has worked fine - I've not touched inetd since then. Until now - I've >just installed Leafnode, having found Cnews way too abstruse and INN too big >for my needs. Leafnode will not run as a standalone daemon, so I have had to >reinstall inetd. I'm using the "openbsd-inetd" which comes with my distro >(Debian Etch). Uh, inetd has been replaced by xinetd. >I've been unable to find any up-to-date analysis of this version of inetd. >All I can find are a few articles that say, basically "inetd used to be >insecure, most people use xinetd now". Yes. So why not use xinetd?

On 2007-12-06, Unruh <unruh-spam@physics.ubc.ca> wrote: > > > "Magnate" <contact.me@some.other.way> writes: > >>Hi All, > >>Some years ago (late '90s) I stopped using inetd, because there were some >>serious security issues. I think mainly around the portmapper, IIRC. Anyway, >>I moved to making all the services I want to use run as permanent daemons - >>exim, apache etc. etc. > >>This has worked fine - I've not touched inetd since then. Until now - I've >>just installed Leafnode, having found Cnews way too abstruse and INN too big >>for my needs. Leafnode will not run as a standalone daemon, so I have had to >>reinstall inetd. I'm using the "openbsd-inetd" which comes with my distro >>(Debian Etch). > > Uh, inetd has been replaced by xinetd. > I can't see my previous followup yet. I said that leafnode requires inetd. Actually the Ubuntu (and probably Debian) leafnode package requires inetd, I don't know why. If you read /usr/share/doc/leafnode/INSTALL.gz, it tells how you can make leafnode work with xinetd.

"Nico Kadel-Garcia" <nkadel@gmail.com> wrote in message news:d576b18c-5d58-44b7-af99-8ee807a12bb9@e4g2000hsg.googlegroups.com... > On 7 Dec, 12:07, "Magnate" <contact...@some.other.way> wrote: >> Well this is a fine discussion, but could somebody please explain >> *why* xinetd is so much safer than inetd? > > Because editing a single configuration file of inconsistent, limited > and post-parsed format is prone to massive errors that will break > *all* the services. Under xinetd, each service has its own > configuration files and gets edited or managed separately. So > conflicts don't occur when two applications being installed try to > edit the same file at once. > > This is also why Apache now uses config files for individual virtual > hosts or components in httpd/conf.d/*.conf instead of putting them all > in conf/httpd.conf. It's also why most cron servers use crond.d/*, > cron.daily/*, and cron.weekly/* instead of having people directly edit > a single crontab file. > > I'm sure there are lots of other reasons, but this is the big one for > me. Hmm. Notwithstanding that I don't personally find any benefit in these new-fangled multiple-fragment configs (I don't run many web sites nor many cron jobs, and found both easier to configure as single files), that's not particularly a security issue. So I assume that if my current inconsistent, limited and post-parsed configuration file for inetd is working, there's no pressing need to change it (like an unclosed exploit, or something). Which is kind of what I was asking in the first place. I can help thinking that if there was one, somebody would have mentioned it by now. CC

Magnate <contact.me@some.other.way>: > "Nico Kadel-Garcia" <nkadel@gmail.com> wrote in message > news:d576b18c-5d58-44b7-af99-8ee807a12bb9@e4g2000hsg.googlegroups.com... > > On 7 Dec, 12:07, "Magnate" <contact...@some.other.way> wrote: > >> Well this is a fine discussion, but could somebody please explain > >> *why* xinetd is so much safer than inetd? > > > > Because editing a single configuration file of inconsistent, limited > > and post-parsed format is prone to massive errors that will break > > *all* the services. Under xinetd, each service has its own > > configuration files and gets edited or managed separately. So > > conflicts don't occur when two applications being installed try to > > edit the same file at once. Excellent point. > > This is also why Apache now uses config files for individual virtual > > hosts or components in httpd/conf.d/*.conf instead of putting them all > > in conf/httpd.conf. It's also why most cron servers use crond.d/*, > > cron.daily/*, and cron.weekly/* instead of having people directly edit > > a single crontab file. > > Hmm. Notwithstanding that I don't personally find any benefit in these > new-fangled multiple-fragment configs (I don't run many web sites nor many > cron jobs, and found both easier to configure as single files), that's not Oh come on. The Debian /etc/cron.{daily,weekly,monthly} scheme is great. Drop a script into any of those dirs and it just works (assuming it works from commandline and you know cron's environment). > particularly a security issue. So I assume that if my current > inconsistent, limited and post-parsed configuration file for inetd > is working, there's no pressing need to change it (like an unclosed > exploit, or something). Which is kind of what I was asking in the > first place. I can help thinking that if there was one, somebody > would have mentioned it by now. I appreciated your asking the question. I'd like the scoop too, and I'm not using it for anything more than identd. :-) -- Any technology distinguishable from magic is insufficiently advanced. (*) http://blinkynet.net/comp/uip5.html Linux Counter #80292 - - http://www.faqs.org/rfcs/rfc1855.html Please, don't Cc: me.

"s. keeling" <keeling@nucleus.com> wrote in message news:slrnflsddf.8cr.keeling@heretic.nucleus.com... > Magnate <contact.me@some.other.way>: >> "Nico Kadel-Garcia" <nkadel@gmail.com> wrote in message >> news:d576b18c-5d58-44b7-af99-8ee807a12bb9@e4g2000hsg.googlegroups.com... >> > On 7 Dec, 12:07, "Magnate" <contact...@some.other.way> wrote: >> >> Well this is a fine discussion, but could somebody please explain >> >> *why* xinetd is so much safer than inetd? >> > >> > Because editing a single configuration file of inconsistent, limited >> > and post-parsed format is prone to massive errors that will break >> > *all* the services. Under xinetd, each service has its own >> > configuration files and gets edited or managed separately. So >> > conflicts don't occur when two applications being installed try to >> > edit the same file at once. > > Excellent point. > >> > This is also why Apache now uses config files for individual virtual >> > hosts or components in httpd/conf.d/*.conf instead of putting them all >> > in conf/httpd.conf. It's also why most cron servers use crond.d/*, >> > cron.daily/*, and cron.weekly/* instead of having people directly edit >> > a single crontab file. >> >> Hmm. Notwithstanding that I don't personally find any benefit in these >> new-fangled multiple-fragment configs (I don't run many web sites nor >> many >> cron jobs, and found both easier to configure as single files), that's >> not > > Oh come on. The Debian /etc/cron.{daily,weekly,monthly} scheme > is great. Drop a script into any of those dirs and it just works > (assuming it works from commandline and you know cron's environment). I'll grant you that - when I wrote the above I was thinking more of apache2 being quite a lot harder to understand and configure than apache. Yes, the Debian cron scheme is great (as is quite a lot about Debian, IMO), though it bugs me that some packages still edit crontab instead of, as you say, placing scripts in those dirs. >> particularly a security issue. So I assume that if my current >> inconsistent, limited and post-parsed configuration file for inetd >> is working, there's no pressing need to change it (like an unclosed >> exploit, or something). Which is kind of what I was asking in the >> first place. I can help thinking that if there was one, somebody >> would have mentioned it by now. > > I appreciated your asking the question. I'd like the scoop too, and > I'm not using it for anything more than identd. :-) Well, I'm only using it for leafnode, and as soon as leafnode 2.x makes its way into stable (or I need for some other reason to dist-upgrade my box to testing), I'll close it down again to be on the safe side. I wish I knew more about security holes in Linux, but there are only so many hours in a day. CC

On 2007-12-16, James Hess <mysidia-unet@darkfire.net> wrote: > > A standalone daemon (such as apache) is preferable in many ways; > forking a new process for each connection is not very scalable, except > for serving a fairly small number of connections. The OP specifically stated that he is trying to run leafnode. leafnode version 1 can not function as a standalone daemon, so it must be run from some sort of superserver. (And leafnode is not meant to serve hundreds of users, either, so it fits the "small number of connections" criterion.) > It is very much a pain to define a xinetd service by hand, compared to > the ease of a single inetd.conf line; you have many more options you > need to consider to fully configure a service using xinetd. I'm not sure I agree. If you have a basic skeleton configuration for a typical service run out of xinetd, then you can use that as your base for other services, which should not need much (if any) modification. > If you do it correctly it won't. There's nothing really inconsistent > about inetd.conf configuration... No, but if you make a mistake (we all have!) configuring inetd.conf, *all* your inetd services are hosed. If you make a mistake configuring an xinetd config file, that service is hosed, but the rest run fine. > In practice very few important services run from inetd (the rest are > standalone servers), so inetd dying when you reload it, until you > can fix the config, isn't much of a concern. If you run more than one service from x/inetd, then it is a concern. You can also consolidate your xinetd configuration into one file if you prefer; the distributions tend to split them by service, but I have one xinetd.conf file with four services configured there. Splitting out by service makes it easier for an automated tool to clobber (or back up) an old config file and write a new file without modifying other services (if you like automated tools messing with your config files). The rest of your comments amount to sysadmin preference. Some prefer the inetd approach, others the xinetd. I'm fairly agnostic myself, and do choose from both when I need to (which isn't often). --keith -- kkeller-usenet@wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt see X- headers for PGP signature information