cvs commit: src/lib/libc/gen syslog.c

[Gleb Smirnoff]

  Andrea,

dwmalone promised to spent some time on this. We together will find
some better approach then reverting commit, or leaving it untouched.
One of current working ideas is to create an additional socket for
priveleged applications, runnning with uid 0, which can't be considered
attackers. Use different policies on these two sockets: priveleged
and default.

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

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE