Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754971Ab1FZU04 (ORCPT ); Sun, 26 Jun 2011 16:26:56 -0400 Received: from mail-bw0-f46.google.com ([209.85.214.46]:37691 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753605Ab1FZUZZ (ORCPT ); Sun, 26 Jun 2011 16:25:25 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=N7nniTMfn/bGVrJdL5hHr7MfU3/EXGyUEWtEpBXa7BSQj14CjR4JmnXjvIuML+X040 4dWHknRk0upWF2CL51SuHxBUXeroFl0+9zjeuWN7aurE6kewThN5HECX3JEmAzmV+88v PuklkXkKReoEo05XcJfQs3E6c1IEo01/AMMfg= Date: Mon, 27 Jun 2011 00:25:18 +0400 From: Vasiliy Kulikov To: Ingo Molnar Cc: Andrew Morton , James Morris , Namhyung Kim , Greg Kroah-Hartman , kernel-hardening@lists.openwall.com, linux-kernel@vger.kernel.org, Alan Cox , Linus Torvalds Subject: Re: [PATCH v2] kernel: escape non-ASCII and control characters in printk() Message-ID: <20110626202518.GA4915@albatros> References: <20110623152137.GA2536@albatros> <20110626103915.GB11093@elte.hu> <20110626165409.GA2584@albatros> <20110626182628.GA20158@elte.hu> <20110626190622.GB4217@albatros> <20110626194618.GA21740@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110626194618.GA21740@elte.hu> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3239 Lines: 78 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". > > > 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. > 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. > > > 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. -- 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/