On Thursday 26 July 2007 12:14:06 Andrew Morton wrote:
> On Thu, 26 Jul 2007 11:46:23 +0200 Andi Kleen <[email protected]> wrote:
>
> >
> > > Look: if there's a way in which an unprivileged user can trigger a printk
> > > we fix it, end of story.
> >
> > I'm firmly against disabling it on x86-64 by default.
>
> We know you are, and the consensus and past practice disagree with you, as
> you well know.
Well that doesn't mean that the practice makes much sense.
Security (which is probably too strong a word for these relatively
weak DoS anyways; it's not like anybody's data gets leaked like
Alan hinted at with his bogus analogy) is only useful if it's perfect; if it
has holes that cannot be plugged it is just wasted effort and likely
harming other good causes (like bug free software)
> > The printks are extremly
> > useful and have found many bugs in the past.
>
> So you turn it on if your applications are playing up. bfd.
You might not know applications are segfaulting. e.g. when I originally
enabled it we found that a few obscure cases in a default system
were occasionally segfaulting, but nobody noticed because there
wasn't a really visible malfunction. Still fixing those made
a better system.
> Still waiting for your report of all the other means by which unpriviliged
> users can spam the logs, btw. Of course, your attitude here makes a
> mockery of all our other care and effort in this area.
One standard way is to overflow the socket limits or the TCP memory allocation
for example. Or just run the system out of memory; that will get plenty of logs
(don't say ulimit now, you know as well as me that they are not good enough
to prevent oom from users). Or use an unaligned a.out executable.
That was just from a quick look, I'm sure there are more.
Some of these are rate limited, but rate limiting just means it will take longer
to fill the disk.
There are also a couple (rate limited ones) that can be triggered from the network.
Anyways if you feel strongly about it then rate limit the x86-64 ones
(Masoud's patch did this anyways); but please don't turn them off.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
