On Tue, Jan 08, 2008 at 07:26:42PM +0200, Jussi Peltola wrote:
> On Tue, Jan 08, 2008 at 10:48:41AM -0500, Douglas A. Tutty wrote:
> > I suppose the only way to have a "trusted-secure" box and an
> > "untrusted-insecure" box with one disply/keyboard would be a KVM.
> This is pretty much the case - depends on what you want to trust. If you
> trust the X server and the OS kernel, you can run a separate X server
> for another user, or VNC, which is somewhat safer than X clients sharing
> one X server (but VNC clients can and do have bugs).
> 
> In any case, if you want to interact with an online bank you will always
> have to trust something to communicate over the network. It's all about
> what you want to defend against and what kind of usablility degradation
> you want to accept.
>

See an idea below.  Isn't it that if you trust the box you are on, and
you trust the https system, then any boxes or network between you and
the bank should be of no concern?  

> > Please tell me that there's no way for a compromised box to do keystroke
> > monitoring of a kvm.
> With a mechanical one you are safe, but all usable KVM switches have a
> CPU and software - you don't get the source, and you have no choice but
> to trust it. In the case of USB the software is probably pretty complex
> and could very well contain exploitable bugs. I wouldn't be surprised if
> some KVMs had flash, which would allow complete compromise of it if you
> found a way to run code on it.
> 
> Actual, physical separation of the machines is the only 100% secure way
> to prevent information from leaking between them. I'd be more worried
> about the network cable between them than a KVM, though.

Even with a firewall running on _both_ boxes?  Sure, if the one box is
compromized that doesn't help, but the firewall on the other box surely
helps.

> 
> You also shouldn't forget yet another link between the machines - the
> user. I've typed passwords and other sensitive things to the wrong
> machine more than once when tired, and a KVM probably makes that much
> easier than having separate machines that are far enough from each other
> so that you can't look at the wrong screen while typing (if they are
> next to each other, a KVM is better than the confusion of having 2
> keyboards).

How does this setup sound (sorry for the ascii-art)


<internet>
    |
<modem>
    |
"entertainment" box
        with its own firwall running.  Call this a Debian box with
        Shorewall.  Used to browse the web if either Javascript or Flash are
        required.  Used to watch movies, and other "entertainment" type
        uses.  Any downloaded files go to the /home directory (not
        shared via NFS) which gets rsynced by the "secure" box over ssh
        (with no X forwarding at all).  Set up for easy reinstall should
        a security breach occur.
    |
"secure" box
        Runs OpenBSD.  Used to store all private data.  Runs pf.
        Runs some kind of intrustion detection on the "entertainment"
        box.  Used to run all apps that don't need javascript, flash, or are
        otherwise of no more than nominal concern.  Runs sshd but does
        not listen to the outgoing network (toward "entertainment" and
        the internet).  Can access the bank from here.  But what if the
        bank needs javascript?  This could just be a server with apps
        run from the "access" boxes.
    |
"access" boxes
        Runs OpenBSD.  Used as ssh slim client.  Has a hard drive and
        base install only.  

In this setup, my Athlon64 could (as it is now) be the "entertainment
box" and I would need a new (to me) reliable "secure" box.  Perhaps a
used HP server.  In my experience here, I can run the
non-"entertainment" apps on my 486 reasonably or my P-II just fine.

The entertainment box needs its own entertainment-quality monitor (my
21" drafting CRT) and keyboard.  The access boxes need monitors and
keyboards.  The "secure" server only needs a serial console (if its a
server) which could come from one of the access boxes.

What loopholes have I left?

Doug.

Reply via email to