www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From antonio lain <ant...@hplb.hpl.hp.com>
Subject Re: Re[4]: Maven repository security
Date Wed, 02 Aug 2006 15:15:32 GMT
We also had a couple of issues with jar signing in SmartFrog: 
one is that if you do remote class loading you need to cache "locally"
(or in memory) the jar file before checking it in order to avoid someone
modifying the jar file after you checked it. 
The other is that even if java 2 security gives no privileges to classes
in a jar file still loads them! So if these classes do things that do
not require a permission check (like modifying public static variables)
they are difficult to control. 
We found easier to sub-class a URLClassloader (and then use
getResource() to load resources) to do all that...

I agree on the trust model being the sticky point. Not sure whether it
would help in your context but in SmartFrog we used a delegation model
embedded in X.509 certificates that allows you to represent 
non-hierarchical relationships using linked local names (somewhat like a
subset of SDSI). So you could create a local link with label "antBoss"
to a public key you choose and then talk about "antBoss:committers"
where the ant "boss" is assumed to tag all the valid comitters with the
label "committers" (by issuing  X.509 certificates...). Then, you just
qualify in the SmartFrog description that a component can only load
things from (SELF:antBoss:committers) and the class loaders do the
rest... 

It is still not great but at least you do not trust "apacheBoss" for
everything...

Antonio
 


On Wed, 2006-08-02 at 15:19, Peter Kriens wrote:
> There are a number of verifications. Jarsigner verifies that the
> hashes are ok and the signer file is correctly signed. This is the
> technical integrity that matches traditional checksumming. There is no
> API. You can easily check this by using a JarInputStream/JarFile and getting
> each entry. If the file is signed, the the input stream will do all
> the nasty work for you; it throws an exception when it runs into
> differences.
> 
> This obviously only tells you that the hashes are ok and the file has
> not been tampered with. As a policy, require that the manifest is
> signed and all resources are listed in the manifest. This is not
> mandatory but there are exploits if you don't.
> 
> Next is getting the certificate that was used to sign the jar (which
> can contain a chain). This is trivial, do getCertificates on each Jar
> Entry. Again, I would ensure that ALL entries return the same
> certificates indicating ALL files are signed by All signers.
> 
> Take a look at http://java.sun.com/products/jce/doc/guide/HowToImplAProvider.html#MutualAuth
> 
> It is really not as hard as it sounds. The REAL hard part is the
> Apache trust model.
> 
> Kind regards,
> 
>      Peter Kriens
> 
> 
> 
> 
> 
> Trust is based
> SL> On 02/08/06, Peter Kriens <Peter.Kriens@aqute.biz> wrote:
> >>
> >> 2a. JAR file verification
> >>    Verifying a JAR file is not that hard as it sounds. Jarsigner can
> >>    do it, and it is not that hard to code up. However, why do you need to
> >>    do this? The class loader will do this properly during class loading
> >>    which gives you end-to-end security. Notice that a signed JAR does
> >>    not tell you it is trustworthy, it just tells you who signed it.
> >>    You need to decide how much you trust the signer (or the signer of
> >>    the signer certificate if you use certificate chains).
> 
> 
> SL> I dont think jarsigner does work. This is why ant doesnt have a
> SL> <verifysigned> task; I backed it out once we became aware of all the
> SL> deficiencies of the code. It looks like it works, but it doesnt check
> SL> that a JAR is signed by anyone you trust, and it doesnt change its
> SL> return code depending on whether the thing was validated or not. All
> SL> you can do is look at the output string and hope it doesnt change from
> SL> version to version.
> 
> SL> Maybe java1.4 or 1.5 has the API calls to validate the CA chain of the
> SL> signatures.
> 
> SL> -steve
> SL> -steve


Mime
View raw message