Date: Mon, 11 Oct 2004 09:25:14 +0200 From: Andrea Campi <andrea+freebsd_cvs@webcom.it> To: Gleb Smirnoff <glebius@freebsd.org>, so@freebsd.org Cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/lib/libc/gen syslog.c Message-ID: <20041011072514.GA37395@webcom.it> In-Reply-To: <20041010101612.GB11523@cell.sick.ru> References: <200410082115.i98LFLMU034965@repoman.freebsd.org> <20041009153916.GA2003@webcom.it> <20041009212952.GA8922@cell.sick.ru> <200410082115.i98LFLMU034965@repoman.freebsd.org> <20041009153916.GA2003@webcom.it> <20041009190714.GB1093@green.homeunix.org> <20041010072205.GA1617@webcom.it> <20041010101612.GB11523@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 10, 2004 at 02:16:12PM +0400, Gleb Smirnoff wrote: > Forget about UDP. syslog(3) logs to local syslogd. The latter may > forward message to other machine via UDP, but this is out of > scope of our discussion. Uhm... right, I was confused and I apologize for that. I now see that UDP has nothing to do with it; and an ENOBUFS situation is probably as serious as you mention. This makes most of my arguments somewhat bogus... But not totally: > 1. Not forever. You keep stating that, but you don't prove it. > 2. This is design error if logging thread holds a mutex, that stops > the application at all. Probably, but POLA dictates that you shouldn't go out on a limb and break applications that happened to get away with it. > A> Above all however, how can you say "not forever"? What kind of guarantee > A> do you see that the application will never succeed its send() call? > A> Sure, statistically it will succeed, but that is not good enough. > > It will wait until syslogd processes other messages on the queue. ... and the calling thread manages to get a timeslice (on a severely overloaded machine as you say) before other threads bog it down again. > A> Note that I'm not advocating that "since it can fail, don't bother > A> retrying". The concept of trying again is fine--my only gripe is with > A> retrying an unbounded number of times. > > That means: "I'd suggest that we leave a possibility to lose messages. > Let it be harder to DoS logging, but possible." Exactly. My point being that a syslog DoS is orders of magnitude less important *on a generic, out-of-the-box installation* that an application DoS. More advanced, security-conscious installations can do what they want, but the default should be fairer than that. > A> - syslog() and family are unreliable functions (to the extent that they > A> even return void; > > POSIX specification > http://www.opengroup.org/onlinepubs/000095399/functions/syslog.html > does not say anything about reliability. > > However, one can understand words "The syslog() function shall send a > message to an implementation-defined logging facility" as "message > should be delivered to local logging facility". Should is not MUST ;-) > A> - if the change stays, I think it should be documented in the syslog(3) > A> man page; > > Agreed. Thanks. > A> - I strongly object to MFC'ing it; > A> - look into a better way to accomplish the goal. > > To continue argument, you need a test case, which shows that some test > application works slower by an order of magnitude or even stops, when > an attacker floods syslogd. killall -STOP syslogd was mentioned in a later answer (although I do agree that's a contrived example). Even worse, this probably means a local user that is able to generate enough syslog calls to cause an ENOBUFS condition can DoS the whole system. I imagine this can't be too hard to do if the system has a serial console at 9600... Sorry, I don't want to be disrespectful or anything but I have no interest (nor time) in continuing this discussion as I feel we both explained our points of view. However, I feel this is serious enough to bring it up with so@; I'll submit to whatever they think of this. Bye, Andrea -- The three Rs of Microsoft support: Retry, Reboot, Reinstall.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041011072514.GA37395>