Pre-auth jenkins auth

[Travis]

Hi Jenkins Devs,

After the last jenkins pre-auth RCE issue, i've been exploring adding an auth layer in front of jenkins. Naturally apache mod_proxy and some basic auth should be a simple solution. https://wiki.jenkins-ci.org/display/JENKINS/Apache+frontend+for+security

However this interferes with:

/jenkins-master/core/src/main/java/hudson/security/BasicAuthenticationFilter.java

/jenkins-master/war/src/main/webapp/WEB-INF/security/SecurityFilters.groovy

So the solution is to remove this filter, fix this design or squash the basic auth headers after apache has processed them, but before proxying to jenkins:

http://stackoverflow.com/questions/4428903/remove-basic-authentication-header-with-apache-mod-proxy

Since other users should be considering the same, could we:

1. Get something better documented then https://wiki.jenkins-ci.org/display/JENKINS/Apache+frontend+for+security, that shows how todo basic auth and still enable jenkin's auth.

2. Get the expert devs to consider a change that won't require messing with auth headers or even a mod_proxy instance?

3. Restructure jenkins auth so the option exists to block 99.8% of jenkin's attack surface using built-in jenkins auth. Currently you can enable auth and enable all the security you want, but jenkins still exposes to much functionality/attack surface.

[Daniel Beck]

On 26.02.2016, at 16:08, Travis <trav...@gmail.com> wrote:

> Naturally apache mod_proxy and some basic auth should be a simple solution.

The Reverse Proxy Auth Plugin allows using the Apache authentication information for authorization in Jenkins.

> So the solution is to remove this filter, fix this design or squash the basic auth headers after apache has processed them, but before proxying to jenkins:

I expect this will completely break API access, as it needs a way to authenticate with HTTP headers that is available to Jenkins for authorization. I'm not aware of a way to chain authentications, so reusing the Basic authentication you have for the application, as described above, seems to be the way to go.

> Currently you can enable auth and enable all the security you want, but jenkins still exposes to much functionality/attack surface.

The TCP agent listener port can be disabled in the security configuration, and between that and locking down HTTP(S), you should be safe from the vast majority of potential attacks that don't require user interaction. Of course, this will remove your ability to use slaves/distributed builds, and makes use of the CLI more difficult/fragile.

FWIW I only remember one "medium" vulnerability in Jenkins configured to have no Overall/Read permission for anonymous users (CVE-2015-5321), that would be prevented by having all URLs protected using basic auth by a reverse proxy. If you know of more, please let us know: https://wiki.jenkins-ci.org/display/JENKINS/Security+Advisories#SecurityAdvisories-ReportSecurityProblems