qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Karl Magdsick <kmagnum@gmail.com>
To: bochnig@pool.math.tu-berlin.de, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] building a virus-proof PC with Qemu
Date: Tue, 23 Nov 2004 17:41:14 -0500	[thread overview]
Message-ID: <cd8ecdef041123144123e6e08b@mail.gmail.com> (raw)
In-Reply-To: <41A3A983.9030100@gmx.com>

> 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

  reply	other threads:[~2004-11-23 22:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-23 12:31 [Qemu-devel] building a virus-proof PC with Qemu Piotras
2004-11-23 12:44 ` Bochnig, Martin
2004-11-23 14:00   ` Magnus Damm
2004-11-23 14:56   ` Magnus Damm
2004-11-23 15:19     ` Paul Brook
2004-11-23 17:37     ` Piotras
2004-11-23 21:20       ` Bochnig, Martin
2004-11-23 22:41         ` Karl Magdsick [this message]
2004-11-23 23:33           ` Magnus Damm
2004-11-23 12:46 ` Andreu Escudero
2004-11-23 13:41   ` Philipp Gühring
2004-11-23 14:38     ` Magnus Damm
2004-11-23 12:54 ` Paul Brook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cd8ecdef041123144123e6e08b@mail.gmail.com \
    --to=kmagnum@gmail.com \
    --cc=bochnig@pool.math.tu-berlin.de \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).