[Cs22800] Robustness of BSD Sebek port, methods for covert transmission

[Mike O'Donnell]

For Ben's project porting Sebek to BSD, I find the proposal nice and
clear and sensible, and the Web presentation very helpful. I encourage
you others to work on nice presentations, and in particular to think
about running your own project diary.

Robustness of BSD Sebek port
----------------------------

Regarding the port, I hope we can get into one more layer of detail
soon. In particular, I wonder how robust the port can be
w.r.t. further changes to Sebek. Will Ben, or his successor, need to
do additional configuration work for each such change? Or, can we
provide patches to the core Sebek group so that they can produce a
distribution that compiles automatically to BSD as well as Linux.

The answer depends to some degree on how the core Sebek project is
organized. Have they used the autoconf/automake/libtool types of
tools, and if so, how well? I've done a bit of this, and it seems like
a horrible black art. The individual pieces of documentation for make,
autoconf, automake, libtool are hard to integrate into an
understanding of the whole task. Somewhere in the Gnome project's Web
space I found a pretty good how-to for the whole thing, at least in
one reasonably workable style.

I expect that, no matter how well autoconfiscated the package is, from
time to time the Sebek core will exercise some new aspect of the Linux
kernel that has to be translated to BSD form. But the number of such
incidents could probably be cut by a factor of 5 or so with good
organization.

Covert transmission
-------------------

This isn't Ben's chosen topic, but we might as well think about the
whole Sebek project a bit. In the note from Ed that Ben posted on 28
September, there's a lot of influence on the problem of dumping
Sebek's data to another host across a LAN without arousing the
intruder's suspicions. That sounds inherently difficult to me. Is it
feasible, instead, to use a separate network connection for dumping
Sebek data? This could be a separate ethernet, or just a parallel port
or a serial port, or maybe a USB. It looks to me like the big question
is how well can you hide such a port and its activity from the
intruder. In principle, it sounds very feasible. Take the device
driver code, and hide it in a file somewhere, and invoke it directly
instead of using the usual /dev interface. If this works, in principle
you might even write to a covert disk, or better a write-once
device. But there might be snags in the details. And the attempt to
have a covert peripheral device might run afoul of attempts to make
device detection and configuration automatic---maybe a modern BIOS
will even interfere.

Anybody know any more about the reasons for sticking to the regular
network connection, which the intruder can easily sniff? Or perhaps
somebody can find this in the Sebek mailing list archives.

Mike O'D.