2010-05-26 10:35, Caleb James DeLisle skrev: > > Andreas Jonsson 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. >> > There is a bug open on this XWIKI-5024 >
Can't read that one. I get a "permission violation" in Jira. Is there a proposed solution? Care to let me in so I can comment on it? > >> 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. >> > I disagree, this will lead to scripts running with various permissions which > will cause them to break unexpectedly and need additional code to handle > more situations. > > Security is hard. When designing an application that have privileges certain care must be taken. The security model must enforce this. > I think the script should execute "as the programmer" and it's the > programmer's > responsibility to keep track of which user is responsible for running the > script. > > So the only option is that all scripts are executed with "setuid"-rights? That seems very dangerous. This will lead to many security exploits. >> 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. >> > When they can, this is a bug. > > I'm sorry, but I do not understand this comment. >> 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. >> > XWIKI-5024 > > >> 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. >> > Then could I not just set a trap for more privileged users by turning the > "programmer" setting off? > What do you mean with "turning the programmer settinng off". In my proposal, a document which doesn't have a programmer set will run without privileges. Setting the programmer must be explicitly confirmed by the user that saves the page. Also, please do not confuse the "programmer" role with the "programming" right. Any user can take on the role as the programmer of the document. (But only users with "programming"-rights can set the programmer to any user.) Maybe a different name would be appropriate for the role to avoid confusion. >> 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. >> > or "XWikiGuest" > > Yes. >> 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. >> > Sounds like a hack to avoid the limitation that objects cannot have an > author as documents do. > > I think that rights should be granted when accessing a document, and only the actual contents of the document should be rendered with those rights. The default should be to render content without privileges. I would not label this as a "hack". Inserting a point cut to grant rights before rendering comments would increase complexity and I do not see the point in having privileged scripts executed in comments. >> 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." >> > Currently (as of 2.3) the equivalent are the api functions: > xwiki.getDocumentAsAuthor > doc.saveAsAuthor > doc.deleteAsAuthor > > These are not at all equivalent. Actually, if the "author" of the document automatically takes on the programmer role the above methods would be blatant security holes. >> 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. >> > I don't understand the difference between this and "save as programmer". > > "save with me as programmer" executes the script with the intersection of the users and the programmers rights; "save with me as programmer and lend my rights..." executes the script with the programmers full privileges. >> 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. >> > PR is god. A PR user can change the author field on a document. > > It is vital that even users with programming rights must explicitly confirm any save that sets the programmer and setuid flag of the document. Without confirmation it would be almost trivial for an attacker to trick a PR-user to set the programmer of an arbitrary script. >> 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, >> > I disagree, I think this would add complication which is statistically > proven to increase the number of security issues. > > Of course I sympathize with the general sentiment that complexity is bad. But there is a minimum level of complexity needed to implement a reasonable security model. >> 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. >> > Modifies database schema. > > >> 2. Add "execute scripts with the programmers privilege (setuid)"-flag >> to document. >> >> 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. >> > Agreed on this point. > > >> The special treatment when the document author happens to have >> programming rights must be removed. >> > Also agreed but that is a big API break. > > >> 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. >> >> 9. Fix all applications that undoubtly will be broken by this change. >> > This will break a lot of apps written by users. > > Can't be helped. More user applications will be written as time passes. The situation will only get worse. >> Do you other people agree with me when I say that the security model >> must be replaced immediately? >> > Yes replaced but not immediately. > IMO a security manager to sandbox core code is more urgent. > > How is this security manager supposed to work? What issues does it solve? >> What do you think about my suggestion? >> Please, poke at it to try to find any attacks that I have not >> thought of. >> > I'd have to see code before I can start attacking it. > > >> 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. >> > Great that you're doing something. > I am concerned that your code may not fit with the direction of the model > but a proof of concept piece would still be great. > > I am partial to the concept of a permission being an unforgable object > which may be passed from one user to another and user Alice may create > a proxy object and pass it to Bob while holding a reference to a bit which > would disable the proxy object thus revoking Bob's authority. I like this > idea for it's simplicity since the security model would only depend on > preventing these objects from being viewed by unauthorized users. It would > also be fast because all of the user's permission objects would reside in > the same place. > > > Caleb > > > >> >> 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 > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
