linux-kernel - Re: i386-show-unhandled-signals-v3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200707261359.46936.ak@suse.de>
Date:	Thu, 26 Jul 2007 13:59:46 +0200
From:	Andi Kleen <ak@...e.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"Masoud Sharbiani" <masouds@...gle.com>,
	"Kirill Korotaev" <dev@...nvz.org>, linux-kernel@...r.kernel.org
Subject: Re: i386-show-unhandled-signals-v3

On Thursday 26 July 2007 12:14:06 Andrew Morton wrote:
> On Thu, 26 Jul 2007 11:46:23 +0200 Andi Kleen <ak@...e.de> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/