> > What about a screen in Jenkins Admin that lists all the "breaking" > security fixes since the release of the LTS. By default after an update > any new security fixes are in "Unacknowledged mode". Having any > unacknowledged items adds a banner to the entire application.
Yes, it's reasonable. Since nobody else likes System properties, a global config seems to be the the only way. Yeah, it is a nice idea, I just wonder if the developers available to > work on security fixes have the time to do that much polish. > The pending SECURITY pull requests have been created by CloudBees engineers. If the community decides that breaking changes cannot be accepted without Advanced SECURITY vulnerability management engine or whatever rocket-science thing, we can go back to our Product Management and discuss it (such implementation was out the initial scope). My concern is that any UI-based implementation requires something very flexible in order to deliver security fixes into 1.625.x. I suppose CERT team agrees that the risks are important enough to be considered for the backporting. - I would vote for a new Restricted extension point in the core + a new bundled plugin, which provides the configurable proposed by Thomas. - I bet somebody will shut down the bundled plugin idea immediately среда, 16 сентября 2015 г., 1:41:19 UTC+3 пользователь Kohsuke Kawaguchi написал: > > I don't think everyone is basically agreeing and the contention points > appear to be small, but we can't make blanket statements like "the security > hole trumps backwards compatibility." It's obviously more nuanced than > that. Generally we tried to keep both goals. > > Fortunately, so far as I recall for most issues, we didn't have to break > backward compatibility and in doing so we didn't feel like we had to make > the fix "ugly." SECURITY-144 was a complicated example --- it added a new > API (which we generally try to avoid in security fixes) but it was not a > binary incompatible change. > > The situation we need to avoid is to require a non-trivial number of > plugins to be updated as a part of the core update. We cannot coordinate > fixes in those plugins with core release due to the way security fixes are > prepared, and users have no effective means to update them all in one. > > There are also many users who don't care about the vulnerability the fix > is addressing, and we want to make sure fixes are not affecting them. > > And above all, if we end up creating a perception that security fixes are > risky, that's very dangerous. And it's hard to win back that kind of trust > once we lose them. > > Those are some of the arguments why backward compatibility is important, > and why we have to have damn good reasons if we are going to break them. > > 2015-09-15 3:39 GMT-07:00 Stephen Connolly <[email protected] > <javascript:>>: > >> 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] <javascript:>. >> 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. >> > > > > -- > Kohsuke Kawaguchi > -- 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/90c61e3f-2bb7-4a33-91e6-9b6c54cb2076%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
