From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CWjWB-0004z7-K9 for qemu-devel@nongnu.org; Tue, 23 Nov 2004 17:52:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CWjW9-0004xp-JI for qemu-devel@nongnu.org; Tue, 23 Nov 2004 17:52:13 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CWjW9-0004xQ-9C for qemu-devel@nongnu.org; Tue, 23 Nov 2004 17:52:13 -0500 Received: from [64.233.184.205] (helo=wproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CWjMk-0000uy-AZ for qemu-devel@nongnu.org; Tue, 23 Nov 2004 17:42:30 -0500 Received: by wproxy.gmail.com with SMTP id 57so45107wri for ; Tue, 23 Nov 2004 14:42:27 -0800 (PST) Message-ID: Date: Tue, 23 Nov 2004 17:41:14 -0500 From: Karl Magdsick Subject: Re: [Qemu-devel] building a virus-proof PC with Qemu In-Reply-To: <41A3A983.9030100@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41A33090.9080703@gmx.com> <1101221775.8460.44.camel@localhost> <41A3A983.9030100@gmx.com> Reply-To: Karl Magdsick , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: bochnig@pool.math.tu-berlin.de, qemu-devel@nongnu.org > sorry, but why don't you use/recommend Trusted Solaris (SPARC and i386) > http://wwws.sun.com/software/solaris/trustedsolaris/ ? > I hardly doubt that it will be too easy for anyone to clone the security > mechanisms it provides. I agree that making the operating system role-aware seems like a much more tractable solution than trying to externally trace data flows. An external system would have to be extremely intelligent in order to work out the Pi calculus from observing data and low-level CPU operations. It is even more difficult to determine which information flows are technically compromising information, but are generally accepted as "safe". Classified processes will often block on file descriptors, which will lead to a thread yielding, and a context switch, perhaps to a non-classified process. This represents a leakage of information, but one that is generally considered acceptable. On the other extreme, a simple scan through memory will not detect passwords being sent over an SSL connection. A simple scan also will not detect SHA-256 sums of passwords being transferred to untrusted processes via shared memory. It's a VERY complicated problem. That being said, a system capable of tracking data flows throughout a system could be useful as a backup to secure operating systems. For instance, before Trusted Solaris was realeased a third party made a hardware firewall product based on x86 Solaris with third-party kernel modifications very similar to Trusted Solaris. The Last Stage of Dementia people were able to leverage a Solaris kernel vulnerability that allowed arbitrary users to install arbitrary call gates. Very skilled coding allowed them to leverage this vulnerability to completely bypass all OS security measures by modifying kernel data structures related to tracking permissions (and win a large cash prize the vendor offered in an attempt to gain publicity for the firewall's "unbreakable" security). There are other products that are very similar to Trusted Solaris. Security Enhanced Linux (SELinux), developed by the US National Security Agency. It also implements role-based mandatory access security. There's a neat demo where they run a vulnerable version of Apache as root and watch people break in to the machine, but the attackers aren't able to do anything b/c the role being used doesn't even allow outgoing TCP connections or reading files outside of the Apache directory. TrustedBSD works similarly to SELinux and Trusted Solaris. I think TrustedBSD is based on FreeBSD, however my only knowledge of TrustedBSD comes from the SELinux mailing list. The Common Criteria certified version of Trusted Solaris used to cost an arm and a leg. I'm not sure how much it costs now. The main reason to use Trusted Solaris is that you are doing work under a government contract that requires a given level of Common Criteria certification. If you're only looking for role-based mandatory access controls, you probably want to look at SELinux and TrustedBSD. -Karl