Mark Crispin (MRC%PANDA@SUMEX-AIM.Stanford.EDU)
Tue, 7 Apr 87 16:06:20 PDT
In a sense your message is very reminiscent of the attitude of the
architects of MIT ITS. It is a useful attitude in certain environments;
it has been argued that the security/integrity consciousness of TOPS-20
and Multics hampered tools development (or limited it to system wizards)
compared to systems such as ITS, WAITS, and Unix. But this does not
mean that it is right for all environments. Even in an environment in
which rwalld is useful, it's important to have safeguards in place to
limit its range. In the present state of affairs, such safeguards are
either absent, not enabled, or inadequately documented.
Just as an example, why did Dennis Perry's system at DARPA accept a
rwall from a machine somewhere at Berkeley? Maybe Berkeley is doing such
time-critical research that breakthroughs must be announced by such
"network shouts", but I think it's much more likely that nobody at DARPA
even knew that such a facility existed or was running on their machine.
Think of what would happen if our IP gateways supported an IP address
of FF.FF.FF.FF (the famous and as-yet mythical "Godzilla-gram").
Fortunately, no gateway does. The same sort of sanity check needs to
be extended to higher-level protocols.
-- Mark --
PS: I could envision a security bug caused by the ability to broadcast
arbitrary characters to terminals on other systems. Are all the rwalld
implementations clever enough to filter out control characters? Also,
those of us who are old enough to know what "cookie bear" know that
broadcasting messages CAN effectively stop all work...
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:06 GMT