> > 1) it greatly simplifies some types of embedded system development.
> > The embedded system is designed to use a SCSI disk, but during
> > development the internal disk is replaced with an external host,
> > typically a developer's workstation. This totally eliminates
> > hassles downloading new files, uploading log files, etc.
>
> It's a lot of extra work... I think that could be done with a dual attached
> SCSI - when updates are to be made the disk is synced/unmounted from the
> test system, mounted/fscked and mounted by the development, update made
> dismounted, test system booted. Most of this could be automated via scripts.
But that approach doesn't allow the embedded software to write to a
log file, with the programmer watching that log with "tail -f". I
actually used a system like this in 1990 or so, under Interactive Unix
with a driver another employee wrote (I think), and it was pretty nice.
I definitely recall pressing buttons on the embedded device and seeing
the log events immediately appear.
BTW, I believe that the approach he used was far closer to NFS than an
attempt to faithfully emulate a hard disk. But I don't know enough of
the details of his design, or UFS(?) file systems, to be sure. As a
developer I simply knew that the embedded device acted like my home
directory was local to it in every way... and we attached the device
via the SCSI port (with the embedded device acting as master).
> > 2) the same approach can be used for stealth monitoring of extremely
> > sensitive systems. An attacker would only see a SCSI hard disk -
> > there is absolutely no way to know that this "disk" is actually
> > physically located and controlled by another system. The standard
> > driver would allow the monitoring system to continually cross-check
> > active and reference files. A somewhat more adventurous driver
> > could implement a type of data logging - the attacker may think
> > he's deleting files, but it monitoring system will retain a complete
> > record.
>
> This shoulds possible, but there might be a tremendous amount of overhead.
> The monitoring system would have to know about the file system (obvious),
> but it would be duplicating the activity of the real host:
>
> [elided]
See above. Also, I think you're overstating the problems with this
approach. The embedded system has to know how to maintain a file system,
but it can be something pretty standard like Minix, UFS, or (ugh) DOS.
The host can map the SCSI requests to an existing partition or file,
and still allow the host access via either regular mounts or the loopback
modules.
The only real problem is caching. If neither system caches the FS
metainformation both should be able to write to it. If only one
doesn't cache, it can still mount it read-only.
> 2. To maintain an audit (and recoverable...) the modifications would
> have to be saved in a journal.
You're thinking in terms of a FS. Don't. All you really need is
something that listens to the SCSI device and accepts "write" and
"read" requests associated with an index. The "journaling" could
be nothing more than a huge circular queue with the following
information:
time, block, old block, new block
This structure isn't practical for FS journaling applications because
it provides no guarantee that the FS structure is uncorrupted - or even
that you'll be able to back out an arbitrary number of changes. However
it is enough that you can rollback the disk image to an arbitrary time
within the last N hours (N depending on usage, of course). You could
even set up a modified reader that gives you access to the FS as it
appeared at any time, although there will be obvious performance problems.
This would be a performance nightmare on a heavily used system, but
I'm thinking this might be a good solution on systems with high profile
but relatively few writes - firewalls, KDCs, etc.
Finally, let me emphasize that I'm not suggesting this is THE solution
to any problem, or even A solution to most. It's much more an advanced
trick that might allow you to perform the impossible in certain highly
unusual circumstances - something akin to the unusual wiretap arrangement
mentioned in _Cookoo's Egg_.
-- Bear Giles bgiles@coyotesong.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:15 EST