Re: Trusted process on an untrusted machine?

From: Tim Newsham (newshamat_private)
Date: Wed Jan 19 2000 - 12:49:56 PST

  • Next message: The Tree of Life: "stream.c - new FreeBSD exploit?"

    > A PhD friend of mine (Rick Kennell) and I spent _alot_ of time discussing
    > how to establish a trusted client on an untrusted machine.  His idea was a
    > customized kernel that would fetch a kernel module off the net at boot
    > time.  The kernel module's purpose would be to verify that the running
    > kernel was intact and had not been subverted (only the known good kernel
    > was running without any unknown modules).  The kernel module would
    > traverse memory and calculate a checksum (maybe of all the memory mapped
    > in the page tables).  The module would then send the checksum back to
    > the central authority who would grant credentials to the untrusted machine
    > if the checksum matched.  This worked off the assumption that the kernel
    > could be trusted to uphold the security of the system.
    > Keep in mind that it would make liberal use of digital signatures and
    > encrypted communication between the client and the central auth.
    
    An attacker can likewise load a kernel module into the kernel that subverts
    its securities, but do so in a way that is no detectable by a simple
    checksum (you never mentioned what you proposed to checksum, anyway, but
    I'm sure once you come up with your list of checksums, I can come up with
    something else to patch, ad infinitum).  Your module will continue to
    pull over its certificates, and my module will continue to use them as
    it sees fit.
    
    > I've left out (and forgotten) many implementation details.  And this makes
    > the assumption that a kernel could be trusted to maintain security once
    > running.
    
    That last assumption is a big one.
    
    > The purpose for the idea was to take the several hundred machines on campus
    > that run linux and turn them into a compute cluster at night.  Unfortunately
    > they would need write permissions to do any useful simulation work and I'm
    > sure we all know how (in)secure linux boxes get when the student body can
    > park their collective asses in front of one.
    
    What is the your threat model?  Do you envision students trying to
    subvert your cluster computations?  Most likely students will be more
    interested in running ftp daemons or irc bots than in fiddling with the
    data in your particle simulations..  I guess what I'm trying to ask is
    "are you expending too much effort to protect something that doesn't
    need to be protected?"
    
    How about something along these lines:
       - have the computers power cycle at a given time each night
       - have them boot over the network from a (more) trusted machine
         or from read-only media, without trusting any of the data on
         the hard drive.  Without running extrenuous services.
       - run the cluster
       - power cycle the machines in the morning before students get on them
    
    In otherwords.. let the users have 1 system on the machines and start
    with a clean slate for your cluster at nights.  Net booting has the
    advantage of letting you upgrade them all easily, too.  And you can
    customize and optimize your kernel for your particular task.
    
    > later,
    > .mike
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:29:16 PDT