While we are doing the JEP review in the pull requests, I would also want to start one topic here. The current JEP-200 design shares the whitelist between Remoting and XStream, and I am a bit aware of that.
The main purpose of whitelisting for Remoting is to allow particular communications between agent and master by saying the class is secure to be sent. For example, Jesse added several JGit classes in Jenkins PR #3120 <https://github.com/jenkinsci/jenkins/pull/3120>. Do we want these classes to be stored on the disk or submitted in config files? Hell no, it may cause behavior and performance issues in Jenkins. But currently there is no way to restrict classes for Remoting-only or XStream-only. So, I would like to put the following proposal on the table: - Allow passing the "SerializationType" (or context) to the CustomClassFilter. Modify the implementation to pass this context - Remoting ClassFilter blacklist should stay global by default, I'd guess - Create 2 new CustomClassFilter implementations, which operate only for Remoting or XStream - Split whitelist resource files: - Remoting: META-INF/hudson.remoting.ClassFilter - XStream: META-INF/ihudson.util.XStream2.ClassFilter (or so) It will allow managing the whitelists individually in plugins if needed. If we eventually have another type of serialization filtering (e.g. for JBoss Marshalling in Pipeline), we will be able to extend the engine easily as well. SerializationType could be made an internal and Restricted extension point in such case. WDYT? BR, Oleg понедельник, 18 декабря 2017 г., 13:41:20 UTC+1 пользователь Oleg Nenashev написал: > > Hi all, > > I am starting this thread in order to collect extra feedback about > JEP-200, which proposes switching Remoting/XStream implementations from a > blacklist to a whitelist. The intention is to significantly reduce risks of > class deserialization attacks, which was hitting Jenkins project seriously > over last 2 years (e.g. SECUIRTY-429 this April > <https://jenkins.io/security/advisory/2017-04-26/>). This JEP is accepted > as a draft, and the current state is published here > <https://github.com/oleg-nenashev/jep/tree/master/jep/200>. > > I am assigned as a BDFL Delegate who makes a decision about > accepting/rejecting this Jenkins Enhancement Proposal (see JEP-1 > <https://github.com/jenkinsci/jep/tree/master/jep/1> for more info about > the process). Over the next week I will be reviewing this JEP and providing > feedback in this thread and in pull requests. > > I also call other interested contributors to comment regarding this JEP. > It is important, because the proposal implies a *high risk *of > regressions in plugins and other Jenkins components. The JEP sponsor made a > significant amount of testing, but there may be some gaps. Any feedback and > extra testing of the reference implementation will be appreciated. > > There are several ways to provide the feedback: > > - Comment in this thread > - Create a pull request with document edits > - Ping me (oleg-nenashev) and Jesse Glick (jglick) in IRC > > My current plan is to finalize the Draft reviews/edits by December 30 > though it depends on the sponsor's availability during the Christmas break > if there is a discussion needed. If you have any comments or interest to > review the JEP deeper, please respond by this date. > > > Best regards, > Oleg Nenashev > > -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/376328d9-fdf7-4595-975f-8fe6afdd5967%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
