Message-ID: <20110626220126.GA24004@elte.hu>
Date:	Mon, 27 Jun 2011 00:01:26 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Vasiliy Kulikov <segoon@...nwall.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	James Morris <jmorris@...ei.org>,
	Namhyung Kim <namhyung@...il.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	kernel-hardening@...ts.openwall.com, linux-kernel@...r.kernel.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2] kernel: escape non-ASCII and control characters in
 printk()


* Vasiliy Kulikov <segoon@...nwall.com> wrote:

> On Sun, Jun 26, 2011 at 21:46 +0200, Ingo Molnar wrote:
> > > > > > Also, i think it would be better to make this opt-out, i.e. 
> > > > > > exclude the handful of control characters that are harmful 
> > > > > > (such as backline and console escape), instead of trying to 
> > > > > > include the known-useful ones.
> > > > > 
> > > > > Do you see any issue with the check above?
> > > > 
> > > > There were clear problems with the first version you posted and 
> > > > that's enough proof to request the exclusion of known-dangerous 
> > > > characters instead of including known-useful characters.
> > > 
> > > It doesn't proof anything.  If I/someone else did a mistake with 
> > > blacklisting would you say it is enough proof to request the 
> > > inclusion of well-known allowed characters?
> > 
> > No, because the problems such a mistake causes are not equivalent: it 
> > would have been far more harmful to not print out the *very real* 
> > product names written in some non-US language than to accidentally 
> > include some control character you did not think of.
> 
> ???
> 
> Not "not print", but print in "crypted" form.  The information is 
> still not lost, you can obviously restore it to the original form, 
> with some effort, but possible.  Compare it with the harm of log 
> spoofing - it is not "restorable".

The harm of 'potential' log spoofing affecting exactly zero known 
users right now, versus the harm of obfuscating the output for a 
known space of USB devices that print in non-US characters, at 
minimum.

> > > > A black list is well-defined: it disables the display of 
> > > > certain characters because they are *known to be dangerous*.
> > > 
> > > What do you do with dangerous characters that are *not yet known* 
> > > to be dangerous?
> > 
> > I'm ready to act on facts only.
> 
> The *fact* is you/anybody/everybody might not know all bad things.  
> If you just don't care because it is yet unknown then you will be 
> vulnerable as soon as it disclosured.

Erm, do you claim that it's not possible to know which characters are 
dangerous and which ones not?

> > Also, i really prefer the policy of acting on known dangers 
> > instead of being afraid of the unknown.
> 
> Do you know the principle "Attacks always get better, never worse"?  
> If you are protected against only of known attack, you will be 
> vulnerable to *every* danger not known to you.
> 
> Maybe you don't know, but it is really possible to be protected 
> against some *yet unknown* attack techniques.  (The assessment of 
> what attacks it protects against is undefined too, though.)  And 
> upstream Linux is *already* protected against some *yet unknown* 
> bugs, not the whole bug classes, but at least small kinds of it.

This claim is silly - do you claim some 'unknown bug' in the ASCII 
printout space?

Cannot you be bothered to enumerate the known 'bad' control and 
escape characters?

You *clearly* did not consider the full utility spectrum in the first 
version of the patch so i think it's necessary due diligence on our 
part to ask you to be more thoughtful with this ...

> > > > A white list on the other hand does it the wrong way around: 
> > > > it tries to put the 'burden of proof' on the useful, good 
> > > > guys - and that's counter-productive really.
> > > 
> > > Really?  I think strict API definition is productive, unlike 
> > > using it in cases where it looks like working, but creating 
> > > tricky and obscure bugs.
> > 
> > You werent really creating a well-defined API here, were you?
> 
> No, I was - only ascii chars and \n are allowed.  In v2 all ascii 
> chars, the upper charset and 2 control chars are allowed.  Rather 
> clear, IMO.

Please enumerate the space you excluded and the reason for exclusion.

Terminals are not some unknown and unknowable space.

Thanks,

	Ingo
--
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/

Powered by blists - more mailing lists