Java configurability

[Adam Shostack <adam@lighthouse.homeport.org>]

Alex Strasheim wrote:

| What are we talking about specifically when we talk about security
| oriented configurability?  Rather than just turning java(script) on and
| off, wouldn't it be useful to piggyback off of the X.509 system that's
| already in place?

| For every CA's or server's cert, they'd just have to add two checkboxes:  
| whether or not to run java applets or javascript code from servers 
| vouched for by those certs.  Is that what people mean when they talk 
| about configurability, or just the ability to shut down java*script) all 
| together?

	I mean the ability to shut down Java or JavaScript (hereafter
called J-code), but not only from a user point of view.  Its
ludicrously easy to convince users to do things that they shouldn't be
doing, so not only do we need a Java off and JavaScript off button
within Netscape, but we also need a means to enforce it at a company
wide level.

	Think about it from the point of view of a business.  There's
this Java software.  You keep reading about how its not really secure
in the press.  Do you trust your users to do the right thing?  You
know how they'll do things like arbitrarily change their IP address
on you.

	So, what do we want as a business?  We want the ability to
define trust.  We want to be able to say what our users can do with
the machines & software we put on their desktop.  We want to be able
to provide them with applets to run.

	This generates a set of needs.  First, we need to be able to
tell Netscape about our corporate policy.  The logical place to do
that is at the HTTP proxy on our firewall.  (Or possibly at a
different port on the machine.)

	Once we have the ability to provide "MUST obey" directives, we
need to ask what those directives should be.  Obviously, we might want
the ability to turn J-code off when passing through this
gateway.

	Next, we would want the ability to allow SELECTED or approved
J-code through.  How do we select it?  It comes from an approved
source.  That source verifies that it created/vetted the code with a
digital signature.  (With an expiration date on it, please.  Code
should need to be re-certified in the light of new bugs in J.)

	The certificate would need to sign a block with at least:

	{<Code block>
	<Valid through>
	<Java Version>
	<Policies approved>}

	Policies?  Thats right.  Java has the potential to do some
really nifty stuff at the corporate level.  Purchasing agents, travel
& reimbursement, etc are the obvious ones.  But those might well need
to be allowed access to disk or network resources.  The fact that I
allow a bit of code signed by the NSA to run doesn't mean I want it to
be as privledged as code written locally.

	Now, the fact that Vericode thinks this code should get disk
access doesn't mean your company does.  So the policy there is a
MAXIMUM level of access that the J-code should get.  I might set it at
less, say, only allowed access to accounting_gw, on port 3456, between
9AM and 5PM.  (I think time controls are a loss, but lots of people
seem to like them.)

	So what would go into a config file?  Things should start
based on a global prohibition.  'That which is not explicitly allowed
is forbidden.'  With the permission of the company, it should be
possible to swap this towards todays setup 'That which is not
forbidden is allowed.'  However, I doubt many companies will go for
that.  None with smart security people will.

	So, having prohibited everything, we now consider if we should 
allowing any of these J-code things to run.  And how do we
discriminate?  Signatures.  So we need to put keys (and fingerprints)
into the config file.

	Once we have keys in the file, we start assigning them
privledges.  "Can examine this file."  "Can examine this list of
files."  "Can write in /tmp, assuming that its less than 80% full."
"Can edit the file /etc/passwd."

	So, is it more clear what I'm looking for?

	(Incidentally, X.509 is a bear.  Read Carl Ellison's comments
last November, and also Ross Anderson's 'Robustness Principles' paper.)

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume