----- "Andreas Jonsson" <[email protected]> wrote: > The work on the new right manager user interface looks very > promising. > Good work! > > But I also think that the underlying security model must urgently be > revised. > > Although I must say that I love the idea that the users can write > their own applications on top of XWiki, the current security just > doesn't support this. > > When executing a script, who should be held accountable for the > actions are taken by the script? > > In traditional operating systems, a user is expected to know and > trust > the programs that he or she chooses to run. Considering how much > problems there are with "viruses" I'd say that this security model > works badly in traditional environments. > > But in a wiki, scripts are executed at any page load. A user who > casually browse the wiki cannot know when and what scripts are > executed. Thus, it is a complete disaster to use a security model > where the users are held accountable for whatever actions the script > is doing. > > For instance, to take over a wiki that is open for anonymous > commenting, just post a script that sits and waits for a user with > admin or programming rights to view the page. > > How can the security model be fixed? > > There are two roles that should be considered involved in the > execution of a script: user and programmer. Both the programmer and > the user should be held accountable for whatever actions are taken by > the script, but neither trust the other. The programmer says "go > ahead and run this script, but you wont be able to do anything that > you don't already have rights to". The user says "sure, I'll go > ahead > and run your script, but I don't give you any rights that you don't > already have." > > Hence, a script should be executed with the intersection of the > rights that the two roles possess. > > But it should be possible for a programmer that have carefully > sanitized the user input to lend his or hers full privileges to the > user. > > It should also be possible for users to indicate that they have > reviewed a script and indicate that they trust a certain scripts or > that they trust some programmer. In other words, the users should be > able to lend their full rights to a particular script or to scripts > written by a trusted programmer, when executed by the user. > > What about contents that is generated by a script? > > If the user who runs a script becomes the programmer of any scripts > that are generated and saved, we have just added one level of > indirection for attackers: An anonymous commenter could post a script > that waits for an administrator. This script should in turn post a > script (whos programmer would then be the administrator) that waits > for an administrator. > > Since both user and programmer should be held accountable for the > actions taken by a script, it might be reasonable that they are also > both credited for any contents generated by the script. Thus both > the > user and the programmer could be considered "the programmer" for any > new scripts generated by a script. But this might be unnecessarily > complex. > > Instead, a distninction could be made on documents that is "saved > with a programmer set" and those that are not. When rendering a > document > that does not have a programmer, all rights should be denied for > scripts in the document. Saving a document with yourself as "the > programmer" must not be allowed without first prompting the user for > a > confirmation, where the user must input a password. This to prevent > attacks where the user is tricked into saving content with to the > programmer set. > > How can this be implemented in XWiki? > > A document has a "creator", which is the person who saved the first > revision of the document and each revision of the document has an > "author", which is the person who saved the revision. We have to > extend the document format to support a "programmer". > > "The user" is of course the logged in user that requests the page. > The user is authenticated the ordinary way and both programmer (if > any) and user is noted in the context. Thereafter any rights check > is > made by checking if both user and programmer has the right. If there > is no programmer, all right checks should return "deny", except maybe > for the "view"-right that should be checked against the user to allow > the include macro without saving with a programmer. (But this opens > up for an attack where page content which aren't viewable by everyone > can be extracted, so maybe not. It could be a configurable option.) > > Obviously, it is important that comments to a page are not rendered > with a programmer set. This will make it impossible to execute > privileged scripts in comments. I don't think that is a useful > feature, anyway. > > This will also require some additional user interaction. The default > should be to not set any programmer when saving a document, and this > will of course not require anything special from the user. > > But when saving a page, it should be possible to select "save with me > set to the programmer". If the user chooses this option, she will be > forwarded to a confirmation page "You are about to save this content > with you set to the programmer. Please confirm by entering your save > password." > > It should also be possible to select "save with me as programmer and > lend my rights to users executing scripts in this page", whereupon > the > confirmation page should be marked with a big warning sign and > contain > a harsh lecture on sanitizing user input. It might be a good idea to > introduce a special "save setuid" right that the user must have in > order to at all be allowed to do this. A user that have programming > rights should additionally have the option to set the programmer to > an > arbitrary user. A setuid script should, of course, have a programmer > with as little privileges as possible. A set of dummy users with > varying privileges could be prepared for this purpose. > > In order to allow saving documents with "the programmer" set in bulk > (for instance in the import application), there should also be a > confirmation page for allowing "saving with programmer set" > throughout > a request. > > Is this sufficient? > > Maybe. We have at least made it a lot harder for attackers, because > now they must trick a privileged user to confirm a "save with myself > as programmer". If the same password is used for saving pages as for > logging in, this can be accomplished by spoofing a login-page. Thus, > there should be a separate "save password" which must differ from the > ordinary login password. > > It might even be possible to allow users to save javascript > extensions. But there should at least be a configurable option to > demand programming rights for this. Javascripts opens up many > attack paths. > > Tasks: > > 1. Add "programmer" attribute to document.
It could be a 'XWiki.ProgramClass' object (to be discussed) > > 2. Add "execute scripts with the programmers privilege (setuid)"-flag > to document. Same, could be a property of said object > > 3. Change the RightService to: > > 1. if a programmer is not set, deny everything except "view", > which > (as a configurable wiki option) can be checked only for the > user > (to allow using the include macro without saving with a > programmer), > > 2. check rights only for the programmer, if the setuid-flag is > set, > > 3. check rights only for user, if the programmer is "trusted" or > the user "trusts" the document, > > 4. check rights for both user and programmer, otherwise. > > Although the current right service implementation can be kludged > into supporting this, it really needs to be rewritten from > scratch, > both for clarity and speed. > > The special treatment when the document author happens to have > programming rights must be removed. > > How to determine if a programmer or the document is "trusted" is > an > open question, but I guess that users with programming or admin > rights, at least, can be considered trusted. > > 4. Add "save password" to the user profile, which must be set to a > non-empty string that differs from the login password for the > user > to be allowed to "save with myself as programmer" or "save > setuid". > > 5. Add user interface controls for saving a page with programmer set. > > 6. Add confirmation page for confirming "save with myself as > programmer". > > 7. Add user interface controls and confirmation page for "save > setuid". > > 8. Add wiki-option to demand programming rights for saving javascript > extensions. FYI it's already the case of "always-use" extensions. (Same for CSS extensions) > > 9. Fix all applications that undoubtly will be broken by this change. The changes listed here are not really backward compatible, so it will be a necessary way anyway, in order to have an application that make use of the programming right in a working state with a new security model. > > Do you other people agree with me when I say that the security model > must be replaced immediately? What do you think about my suggestion? > Please, poke at it to try to find any attacks that I have not > thought of. I'm very +1 to fix the programming right immediately (by that I mean for programmers to declare a page that require to be executed with the programming right). For the rest of the proposal, I have to think more about it before I make my mind. Anyway I think we can improve the security model incrementally - of course the sooner the better. > > I have started on a new right service implementation with a > cacheing front-end. I'll create a new module under core which I'll > call 'xwiki-security' and move the right service to the new > architecture while I'm at it. That's great. Don't hesitate to commit it early in the sandbox so that everyone can look at it. Jerome. > > > Best regards, > > Andreas Jonsson > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
