linux-kernel - Re: [PATCH v2] kernel: escape non-ASCII and control characters in printk()

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 26 Jun 2011 23:06:22 +0400
From:	Vasiliy Kulikov <segoon@...nwall.com>
To:	Ingo Molnar <mingo@...e.hu>
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()

On Sun, Jun 26, 2011 at 20:26 +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?


> 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?


> 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.

Yes, drawing multicolor logs is funny, but ...egrrr...  printk() is not
written for these things.


Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
--
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/