Those of us who are on the jenkins-cert list have probably seen my
comments about how there needs to be some guidance from the community
on how far SECURITY issue fixes can go.
I am starting this thread to try and start compiling that guidance.
The general problem (as I cannot share the specifics outside of the
jenkins-cert list) is as follows:
* User raises a SECURITY issue from noticing some implicitly defined
API of Jenkins has a hole of some sort
* We have to fix the issue, but fixing it will involve changing the
implicitly defined API and thus risking breaking existing "users" of
the implicitly defined API
* Much heated debate around should we leave the old API present and
try and redirect to the new one (thereby leaving the hole open) or
break existing plugins and close the hole.
In some cases it is possible to use a system property to re-enable the
hole for those users who are accepting of the risk... but other cases
require changing class structures (this can range from encapsulating
fields to completely reworking the java class that gets returned)
My view is that a hole is a hole until it is fully plugged, and if
plugging the hole means that some plugins break, well sorry but
SECURITY... now by all means we should seek to minimize that breakage
*while closing the hole*... and where possible we should provide a
System property based switch to re-open the hole for those users who
upgrade and are ok with the risk.
Let's take a semi-concrete example:
In order to fix SECURITY-144 we had to change the interface of
h.r.Callable to include the role checking... being pre-java 8 we
cannot use default methods, so this was a backwards incompatible
change... any plugin that does not implement the role checking method
would potentially be broken... as a result - and after much debate -
it was decided that a majority of people implicitly trust their slaves
as much as the master and so the role checking is likely not required
for maybe 60-70% of installations. Thus the role checking ships off by
default and we implemented a way to whitelist plugins that are
compiled without role-checking support. Thus if you have slaves that
are less trusted than the master you can opt-in to the higher security
requirements... if there are plugins that you need that get broken,
you can white-list those specific plugins if you absolutely need to.
The point here is that we closed the hole. We felt the risk of plugins
being broken was sufficiently high that the hole would not be closed
by default (The plan is to measure the plugins with support for roles
and once above a threshold then turn on secure by default) but when
the security is turned on it is on.
So what kind of things do we need guidance on:
* Some methods of some objects allow you to discover information about
other objects that you do not have permission to discover.
- Do we just protect the ways that we know about and leave the
original method present with a @Restricted(DoNotUse.class) so that
when plugins upgrade their core version they are forced to switch to
the new method; or
- Do we change the contract of the current method (so it now
returns maybe a null or throws an exception or omits entries from a
collection) so that the method does what it was originally supposed to
do but didn't... this may break existing plugins in fun and exciting
ways
* Some objects have public fields that are either mutable or of a type
that needs to be changed in order to remove the hole.
- Do we leave the field as is and just introduce the new accessor
methods - leaves the hole as is... so we have to rely on adding a
stapler action method (since they are higher priority than public
fields) to mask that route to discovery via Web and hope that there
are no other routes to that field...
- Do we say kill that field, you shouldn't have been using it (oh
and let's hire a hitman to find the lazy developer who made a public
field rather than use their IDE to generate getters and setters) and
risk breaking any plugins that actually use the field.
* Some HTTP requests can be used for more than their original intended
purpose. Jenkins Admins may well have discovered this and - rather
than thinking oh look a security issue - used such back doors to do
important things for their instance
- Do we try and make such back-door usage as safe as possible -
which in a sense makes this side-usage officially part of the API of
that HTTP request
- Do we lock the HTTP request down to its original intended
purpose and break any side-effect usage that Jenkins Admins were
hijacking?
There are probably other classes of guidance required, but my brain is
melted trying to derive the classes from the issues I am aware of so I
cannot think of any others at the moment.
It all boils down to the question:
Which is more important, maintaining backwards compatibility or fixing
the security hole.
My view is that fixing the security hole trumps backwards
compatibility, if we have to break a few plugins or a Jenkins admin
has to find a different way to solve their problem... well sorry but
SECURITY... that doesn't mean we should start by breaking backwards
compatibility, rather we should do everything we can to close the hole
while maintaining backwards compatibility... but when that isn't
enough to close the hole (and usually it is not enough BTW)... well we
need to close the hole.
Over to you!
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw6rhFBDP-jjqaaNN8YZoxT1kqGUXR1F9hvDT6s%2B01_Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
