Basically if you can't trust your build machines, you have some issues. If you can't trust the code you are building, you have worse issues.
The current block on releasing the literate plugin is providing a good isolation for pull request builds so that drive-by pull requests on GitHub don't crash your server... As soon as I get that in place I will push the pull request code to literate so people can use it. Would be irresponsible to push the pull request support into literate without such protections. On Tuesday, 29 April 2014, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > > > On Tuesday, 29 April 2014, Mani Azizzadeh > <mani.azizza...@gmail.com<javascript:_e(%7B%7D,'cvml','mani.azizza...@gmail.com');>> > wrote: > >> >> Hey Stephen, >> >> >> Thank you for your answer, just some follow up questions. This setting >> that you are talking about, is it something that is turned on by default? >> What is the setting called? >> > > I can't recall exactly. Basically the master side if the channel can flag > the slave side as untrusted. > > >> So if an attacker should get access to a slave, then he/she cannot just >> execute some arbitrary code or command on the master, right? >> > > Well... Assuming you turn on that setting... First the attacker needs to > get around code signing. Depending on the launch strategy this may not be > that big an issue. > > Next the attacker needs to get an exported object reference. If you don't > have one of them then all you are doing is executing code on the slave side > and the master is safe. > > Once the attacker has an exported object reference then they need that > reference to provide a method that takes a String and parses it as Groovy > or JavaScript and doesn't go through the sandbox. I know of no such > exported object reference, but with 1k plugins there *could* be one. > > Once they get that, they are home and dry... The code they execute on the > master can pull over whatever they want. > > If the channel says both sides are trusted then the attacker just has to > get a ref to the channel to execute remote code.... Remoting will gladly > push over their classes for them. > > Maven job type uses remoting between slave and maven as well as between > slave and master, so that allows a compromised build to *theoretically* hop > all the way to the master. > > Maybe 5-10 people could do such a trickery at present and none of those > that I know would want to. > > >> And if using a freestyle project then the attacker will not even be able >> to inject any custom code to be run on the master? >> > > Never say never > > >> >> Sorry for all the questions... :) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to jenkinsci-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Sent from my phone > -- Sent from my phone -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
