This the response to a couple of questions that came in overnight,
consolidated to reduce bandwidth and cascades.
We handle telnet through a proxy which is encapsulated by Type
Enforcement. That is, it can't be tampered with from other domains
(such as user) even if a person manages to su root in the non-telnet
domain. If you wish to take the performance hit (and spend the
development time -- this is not part of the inital release) you can
pipeline two proxies with an arbitrary intermediary to do things like
force extra authentication, encrypt/decrypt, and/or insert security
labels.
Visitors to the demo suite at Baltimore were told that you couldn't
compile and execute code on a Sidewinder while it was attached to a
network. This was the direction we gave the marketing reps because at
the time we prepared the marketing material we weren't sure that the
limited execution environment would work. Now we are.
Code can be compiled and executed on a Sidewinder from the user
domain, but said code is restricted to "ordinary" operations (the
precise definition of which is subject to the non-disclosure
restriction I mentioned yesterday.) Attempting to do something
"interesting", like get at a network interface, causes an alarm to be
raised and invokes a site-configurable handler -- most of the time
this will log all available data on the process and kill it.
The demonstration/challenge site we will have up on the Internet RSN
will let you log in as a user and demonstrate that you can run user
programs and scripts within the limits we set. (Mail and a bunch of
other stuff will be running to show that we do support Internet
services on the gateway.) The challenge, outlined earlier and to be
described in detail in a couple of days, is to break out of that
environment and get to the protected machine on the other side of the
Sidewinder. Should be fun.
Cheers,
Earl
|
|
