Validation of Signed Application

[obstacleman]

I'd like to have the platform validate signed code on a push at staging time. There are a number of elements to this:

1. There needs to be a way to specify the trusted signing certificate/root - likely BOSH Trusted certs
2. Validate that the cert in the signature block file is valid and trusted (see Start command contains hard-coded references to staging directory #1)
3. Verify the class hashes in MANIFEST.MF
4. Validate the MANIFEST.MF signature

There is also the potential requirement for timestamp signature validation. In the case that the signing certificate is expired when validating - you can still trust the signed code so long as there is a time stamping signature included specifying the signing took place while the cert was still valid. Here's some information on time stamp support: http://docs.oracle.com/javase/7/docs/technotes/guides/security/time-of-signing.html

[nebhale]

@obstacleman A couple of weeks ago I threw together an implementation of a Cloud Foundry application signature verifier. During this I learned that the only reasonable way to actually do signature verification was to re-JAR the application, and read every byte in every entry. This was because the JAR APIs in Java automatically do all the validation you need this way, including knowing the special manifest signature incantations for the JAR itself.

This process is actually pretty quick (I guess a huge JAR might be slow, but it's not terminal) so I don't think we've got an issue there. What strikes me though is that the code I've written is for all intents and purposes the exact same code as exists in jarsigner -verify. Given that I also have to re-JAR the application (since the buildpacks are not provided with the compressed archive) I have to wonder if staging is the proper place for this.

It feels like the CI/CD pipeline that is pushing the application should actually just run jarsigner -verify as the last step before push. Thoughts?

[obstacleman]

I think that from a CI/CD perspective you should verify before you push. The lack of a verified signature should be a gate that would stop the pipeline from doing a push. Given that signing might very well be a part of the pipeline I don't see it as a means of protecting what I'm worried about though.

In my eyes the value of being able to give the platform the cert is that the platform could then reject something that wasn't signed appropriately. It guards against bad actors with access that doesn't necessarily go through your normal pipeline. Does that make sense?

[nebhale]

It makes sense, but why isn't that a credentials issue? If a bad actor has access to cf push, they also have the ability to disable validation with cf set-env <APP> JBP_CONFIG_COMPONENTS .... Or they could even push with a buildpack that isn't the "official" Java Buildpack that simply removes the validation. I'm just not sure that the buildpack is proper place for the validation (even though it's technically possible).

[nebhale]

Since there's been no response on this issue in a couple of weeks, I'm going to close it. If you'd like to see it re-opened, please comment on the issue and I'll reopen it.