cvs commit: src/lib/libc/gen syslog.c
andrea+freebsd_cvs at webcom.it
Mon Oct 11 00:25:17 PDT 2004
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
> 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;
> 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.
The three Rs of Microsoft support: Retry, Reboot, Reinstall.
More information about the cvs-all