[1614] in WWW Security List Archive
Re: Re[2]: Java "security holes'
daemon@ATHENA.MIT.EDU (Albert Lunde)
Wed Mar 13 01:54:35 1996
To: www-security@ns2.rutgers.edu
Date: Tue, 12 Mar 1996 22:12:11 -0600 (CST)
In-Reply-To: <9602128266.AA826678912@CCMAIL.BSIS.COM> from "jing.zhou@ccmail.bsis.com" at Mar 12, 96 04:59:35 pm
Reply-To: Albert-Lunde@nwu.edu (Albert Lunde)
From: Albert-Lunde@nwu.edu (Albert Lunde)
Errors-To: owner-www-security@ns2.rutgers.edu
> > The hard part is the policy, that is, once you have an applet that you
> > *know* comes from Walmart, so what? [...]
> I believe it is still policy problem: Network admin people would prefer
> to centralize the security managment, like firewall. Even if I wrongly
> configure my unix workstation, the public internet sites still can not
> access my workstation. If we allow individual users to open connections,
> then anything could happen without acknowledging admin people. [...]
Prior experience (with stuff like anti-virus software) that the approach
that works the best is one that needs no configuration and offers
the user only choices directly related to things they understand.
So I think a centralized security policy server would be a good idea.
But the problem of _finding_ such a server is non-trivial too, with
IP spoofing and DNS corruption lurking as possible attacks: you'd
want to autheticate your "security policy" server, and do something
prudent if it went off-line (say thru a denial-of-service attack).
I suppose it wouldn't be totally crazy to devote yet another DNS
record type to serving or pointing to this information, since
if you can't trust DNS, how will you find any other server?
I suppose a client could cache some cryptographic information to
verify that the server it is talking to "now" is the same one it
talked to "the last time", which reduces the window for some
spoofing attacks.
I'm no expert, but it seems like there's a lot to worry about.
With mobile computers plus mobile code, a domain-based secuity
policy might be hard to hold together,too.
--
Albert Lunde Albert-Lunde@nwu.edu
