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, 16 Jul 2006 02:51:08 +0200
From:	andrea@...share.com
To:	Valdis.Kletnieks@...edu
Cc:	Pavel Machek <pavel@...e.cz>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	ajwade@...001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com,
	Lee Revell <rlrevell@...-job.com>,
	"Randy.Dunlap" <rdunlap@...otime.net>,
	Andrew Morton <akpm@...l.org>, bunk@...sta.de,
	linux-kernel@...r.kernel.org, mingo@...e.hu
Subject: Re: [2.6 patch] let CONFIG_SECCOMP default to n

On Fri, Jul 14, 2006 at 10:55:28PM -0400, Valdis.Kletnieks@...edu wrote:
> In fact, the best you can do here is to reduce the effective bandwidth
> the signal can have, as Shannon showed quite clearly.

Yes.

> And even 20 years ago, the guys who did the original DoD Orange Book
> requirements understood this - they didn't make a requirement that covert
> channels (both timing and other) be totally closed down, they only made
> a requirement that for higher security configurations the bandwidth of
> the channel be reduced below a specified level...

Why I think it's trivial to guarantee the closure of the seccomp side
channel timing attack even on a very fast internet by simply
introducing the random delay, is that below a certain sampling
frequency you won't be able to extract data from the latencies of the
cache. The max length of the random noise has to be >= of what it
takes to refill the whole cache. Then you won't know if it was a cache
miss or a random introduced delay that generated the slowdown, problem
solved.

As you and Pavel correctly pointed out, you can still communicate
whatever you want over the wire (between the two points) by using a
low enough frequency, but I don't think that has security relevance in
this context.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ