Re[4]: Maven repository security

[Peter Kriens <Pe...@aQute.biz>]

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 <Pe...@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

-- 
Peter Kriens                              Tel +33467542167
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599

Re: Re[4]: Maven repository security

[antonio lain <an...@hplb.hpl.hp.com>]

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 <Pe...@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