On Thu, Dec 21, 2017 at 1:38 PM, Oleg Nenashev <o.v.nenas...@gmail.com> wrote: > 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.
Received. And/or loaded from XML files. > For example, Jesse added several JGit classes in Jenkins PR #3120. Do > we want these classes to be stored on the disk or submitted in config files? IIRC some of these were in fact used in certain cases in `build.xml` files, but I may not be remembering that right. > Hell no, it may cause behavior and performance issues in Jenkins. Which “behavior and performance issues” are you referring to? They sound unrelated to security and are best addressed, if required, by plugin developers on their own initiative. The purpose of the JEP-200 whitelist is to protect the master JVM from deserialization exploits (originally coming from CLI clients, now coming from compromised agents or REST/CLI calls to upload XML). These could come equally from Java Remoting or XStream, usually with the same classes. (Sometimes only from XStream since there is no requirement to implement `Serializable`; anyway is it harmless to Remoting to include an entry which can be exploited only via XStream.) If JBoss Marshalling were exposed to user actions, the class filter would be applied to it as well. But `program.dat` is only ever written by the master to begin with, and `script-security` should block programmatic creation of payloads. > 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 I can think of no reason to do that. It just adds complexity and confuses the issue. -- 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/CANfRfr1EVa8C%2BPX2CbCOcvE4NTZosp_N3i2VbzTar4BpFVcxsw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
