Hi Caleb, I am not sure that I fully get the point about your proposal. If I understand it well, you want to allow users with PR to save document content without giving them PR. I agree this could have some benefit, but this is not really a full cure for existing issues.
BTW, this is not really the list for discussing security matters in details, may I remind you that we have [email protected] for that particular purpose. So I will avoid those details in my reply. At the moment, I do not see the benefit of using a bit for the purpose. I am pretty sure that XObject could be used as well, with the advantage of not introducing any new needs in the data model. Maybe we could even reuse the current RequiredRightClass for the purpose. For example, we only provide PR when PR is required by that XObject, and on save, we delete such object or warn/request confirmation to keep them as appropriate when the content author change the state of PR. This is quite easy to introduce, and have some benefit, but it is far from solving the numerous issue we have with PR, in particular when using sheets, or advanced rendering techniques. Caching the PR state has no benefit, since the security cache already does so. On the more general aspect about the state of security of XWiki, it has been admitted so far, that exploit by user with Edit right is not considered so harmful and a priority. If we decide now that the priority of such exploit is more critical, and I had always been part of those who are paranoid about security, so I am +1 for that, we need to put the security aspect higher in our roadmap, and some of the actual committers to concentrate on that aspect. As you know, I have fully reviewed the Crypto API, and managing signed scripts in XWiki is now technically speaking, just next door. The reason we still have not them is mainly about because the introduction of this feature is a major change, and so far, I have not been able to drive enough attention to it, so to receive feedback and create brainstorming on how we'd like signed script to behave. By itself, signed scripts will provide script integrity and trustable authorship, but we still have to define how we allow script to receive privilege like PR based on the signer(s). Basically, how we manage the web of trust by certifying signers. So far, appart of a fully integrated API, I have written, I hope, an in depth design document ( http://design.xwiki.org/xwiki/bin/view/Design/SignedScripts), which try to reflect all my thoughts about the subject. I understand that it could be frightening to those that are not knowledgable in cryptography, but I have done my best to make it as accessible as possible. What is annoying, is that I haven't received much feedback about the subject. Until now, brainstorming on the subject as not be insightful enough to overcome my paranoia, which is to not introduce solutions that will reveal to be either too complex, flawed to the point that fixing them introduce breakage, or even worse new and potentially definitive security flaw. I am convinced that designing signed scripts could not be a single person decision, and that we need a team to properly define the behavior. This is why I have written the generic technical tools, and that I would be pleased to help and pursue this goal, but I do not want to do it alone. Edy has recently show some interests on the subject, and I am sure that together, we could progress to some solution, but it gets us back to the priorities. So the question for me is: do we now consider that users with edit right is a potential threat, and if so, do we want to push again to get signed script done ? Sorry for the long mail, Thanks, On Mon, Aug 31, 2015 at 5:27 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote: > I like this idea, and we can also enforce the security by adding a checkbox > to explicitly save with programming rights (off by default). > > Maybe not as good as signed scripts, but at least do-able quite easily and > quickly. > > Thanks, > > 2015-08-28 18:25 GMT+02:00 Caleb James DeLisle <[email protected]>: > > > Hello All, > > > > It's been a long time since we first discussed hardening XWiki > Programming > > Rights > > by way of signing scripts in the wiki. As I recall the idea was spawned > > some time > > around 2011 in a conversation between me and Denis but it has had > > difficulty getting > > off the ground. Alex Busenius and I worked together on an early crypto > API > > for XWiki > > but we fell short on getting it tied in to the scripting infrastructure. > > Denis Gervalle > > picked up the task and redeveloped the crypto API but still had not been > > able to reach > > a consensus on how the Signed Scripts should operate. > > > > Thanks to James Kettle reporting some arguably-buggy behavior to us, I > > started thinking > > maybe there is an easier way. I would like to propose a more simple > > alternative to see > > if the community supports it. > > > > 1. Introduce a HAS_PR bit to XWikiDocument, if this bit is set then the > > document has > > programming rights. > > > > 2. Every time a document is saved (at the database level), if the > > contentAuthor does > > not have programming rights, we clear the bit. > > > > 3. The save action will set the bit if appropriate but other methods of > > saving a > > document will not (to prevent bad scripts from tricking users into > > granting PR). > > > > 4. Upon upgrade, we will do a database migration and any document which > > would have > > PR now will have the bit set. > > > > 5. XAR Exports will contain the value of the bit. > > > > > > The idea of the bit is that we can more clearly express intent, if we are > > quite sure > > that not only does the editor have PR but indeed they *want* to grant it > > to the script, > > only then do we set the bit. Furthermore the bit is resistant to > > schenanigans because > > it is inaccessible to velocity scripting, as is an XObject which could > > otherwise also > > be used for this purpose. > > > > The bit can reside in the XWD_ELEMENTS field of the xwikidoc table which > > is intended > > for this purpose. > > > > WDYT? > > > > Caleb > > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Guillaume Delhumeau ([email protected]) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
