> The main module here is zkshim_drv.c. It provides a device driver for
> a device, /dev/clientshim, which provides an interface to the network
> routing functions. The main purpose of this device seems to
> be to allow
> ioctl's which will set routing and firewall rules. It also
> seems to be
> possible to directly read and write the device to get low-level access
> to IP packets. It's not clear whether this latter functionality is
> important or secondary to firewalling which is done in the kernel.
>
Actually this is not quite correct. The shim has no direct interface to
routing whatsoever, it sits in the kernel's IP firewalling hooks, and acts
as a limited packet filtering firewall and ethernet tap. Both features are
quite important.
> zkshim_rules.c maintains a set of rules for how packets
> should be handled.
> Packets can be filtered based on source and destination address, port,
> and other information. If a packet matches one of the rules, it can
> either be allowed to pass through, deleted, or it can be re-routed to
> some other IP/port address. Again, the ioctl provided by
> /dev/clientshim
> is used by client software to set the rules.
>
It is this 'other information' which is key. the primary purpose of this
code is to provide firewall style functionality which, for locally
originating connections, can treat packets differently based on the uid /
pid that originates them. The linux freedom client needs to do this in order
to play friendly with other users which may be using a system concurrently
with a user who is running freedom (and other reasons, but I'll spare you
the gore)
> zkshim_cache.c provides a cache of recently used rule
> entries, apparently
> for performance optimization. zkshim_frag.c deals with the complexity
> of keeping track of packet streams.
>
> That's about it. There is no crypto.
>
This is quite true. I hope it is easy to see however, that this code
provides a direct interface to packets flowing through the kernel IP stack,
such that they can be removed, encrypted, and re-inserted. You are right
though, Freedom does it's crypto and session management in user-land.
> Presumably the way this is used, say the ZKS product wants to protect
> HTTP sessions, which will be recognized as connections to port 80 or
> other commonly used ports. A rule can be installed by the ZKS client
> which will cause any connections to port 80 to be redirected
> to one of the
> ZKS servers. From there it can be forwarded through the
> Freedom network.
> This redirection is all that is done by ZKShim.
>
This is dead wrong. Doing so would imply that the first hop to ZKS servers
would be in the clear. This is not at all the case. Without getting into the
details of how Freedom functions, this first hop is actually local.
> This means that a considerable amount of other processing on each
> connection must be done outside the kernel (or there is more kernel
> code yet to be released). It's not clear how ZKS would hook into,
> say, a Netscape browser and intercept its socket connection calls so
> that it can add crypto and do other functionality beyond the simple
Netscape initiates a TCP connection to a httpd. As you just said, this
connection can be redirected by ioctl()ing logic into the kernel shim. You
must of course have noticed that the shim has two distinct rule types ...
one deals with streams and is hooked into the socket syscalls, the other
deals with packets and sits in the firewalling hooks.
> redirection being done by ZKShim. Perhaps it can use a shared library
> which somehow lies between Netscape and the real system
> shared library?
Hmm, clever. I did look at implementing the functionality your describing
using LD_PRELOAD or ELF filter DLLs (which solve the 'somehow lies' part).
The difficulty with this is that there is too much potential for users to
accidentally change their environment variables for the former, and
hand-hacking .so's is nobody's idea of fun for the latter (nor is having a
hacked lib).
> But if it did that, why couldn't it do the redirection there as well?
> It certainly sounds easier to do it in user space where fragmentation
> issues won't arise.
>
Ultimately what your missing here is the context in which
shim_stream_connect and shim_dgram_connect get called. You're right in that
they never get called directly. If you look at the module initialization
however, you'll notice that we save the addresses of connect() inside tcp
and udp's proto_ops structs, and then replace them with the addresses of
these two functions. It's a little bit of a kludge, but it works quite well.
(And it's safe since we are happily sitting within a lock while we do these
atrocities). This allows us to selectively manipulate socket opertaions
which gives us an efficient transparent proxy mechansim provided your only
interested in proxying locally originated connections.
> One other point: a substantial part of the code in zkshim_drv
> appears to
> be non-functional. shim_inet_stream_connect and
> shim_inet_dgram_connect
> appear to do a lot of the firewalling and redirection work,
> but they are
> static functions pointed to by static structs which are never
> exported.
> There doesn't seem to be any way to enter these functions,
> which amount
> to some 20% of the zkshim_drv.c file.
>
See above.
> Either it's old code which they never got around to removing, or it's
> new code which hasn't been used yet. This suggests that this is far
> from a finished product and substantial work remains to be done on the
> Linux port.
>
Based on the fact that your assumption is incorrect, you'll agree that this
conclusion has little foundation.
> We really can't complain - the release notes did say that
> this was 'not
> functional end-user software'. We may have thought it meant
> that other
> pieces were still to be released, but maybe it actually means that the
> damned thing doesn't work yet.
>
It means, in fact, that other peices are still yet to be released. Indeed
this component does no crypto, yes it is far from an application. It also
happens to be the easiest component of the system to open source since it is
independant of the rest of the application. There is more to come.
Admittedly I do have a bias, but I also am in a rather more informed
position to comment on whether or not the damned thing works. It does work
quite well, although with '(gdb) where' currently burned into my retinae, I
would have to agree with 'damned thing' part.
Cheers
~ol
__________________________________________________________
Disclaimer: My employer doesn't even agree with me about C
indentation style.
