26 May
2010
26 May
'10
9:39 a.m.
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.
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.
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.
9. Fix all applications that undoubtly will be broken by this change.
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 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.
Best regards,
Andreas Jonsson
26 May
26 May
10:35 a.m.
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
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.
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.
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.
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?
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"
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.
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
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".
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.
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.
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.
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:12 a.m.
On 05/26/2010 10:35 AM, Caleb James DeLisle wrote:
You say a script should be executed "as the programmer", but the
programmer should not be able to give his privileges to the script?
Sounds contradicting, which rights should this script have then?
IMO Andreas has a point here, a script written by a "viewer" and run by
an "admin" should (by default) have the same effective rights (=view) as
a script written by an "admin" and run by a "viewer", to prevent
privilege escalations. But the more privileged users should have the
option to write scripts that have more rights, otherwise many scripts
would break.
See above, it's giving the script my rights vs. giving my rights
intersected with rights of the viewer.
Alex
Andreas Jonsson wrote:
<snip>
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.
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.
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.
>
> 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.
>
<snip>
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".
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.
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.
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.
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:40 a.m.
2010-05-26 10:35, Caleb James DeLisle skrev:
Security is hard. When designing an application that have privileges
certain care must be taken. The security model must enforce this.
I'm sorry, but I do not understand this comment.
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.
Yes.
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.
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.
"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 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.
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.
Can't be helped. More user applications will be written as time
passes. The situation will only get worse.
How is this security manager supposed to work? What issues does it solve?
Andreas Jonsson wrote:
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?
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
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.
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.
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?
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"
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.
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
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".
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.
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.
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.
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:30 p.m.
Andreas Jonsson wrote:
Security is hard. When designing an application that have privileges
certain care must be taken. The security model must enforce this.
I'm sorry, but I do not understand this comment.
I guess I didn't understand, I thought you meant is there still a way for the
programmer's
power to leak to the user even if the programmer wants to avoid it.
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.
Meaning cannot load or save any documents?
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.
Yup, it sets the author field to the author of the script that called the
API and saves the document if the author has permission.
Security hole? Please, show an exploit.
"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.
Ok.
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.
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.
IMO it's most important that all security goes through a small bottleneck
of code so there will be fewer bugs in the security code.
It seems that you are mixing code for preventing a malicious user from gaining
unauthorized access which I would call security
with code for preventing a user from accidentally delegating their privileges to
another user which I would call user interface.
Caleb
Can't be helped. More user applications will be written as time
passes. The situation will only get worse.
How is this security manager supposed to work? What issues does it solve?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2010-05-26 10:35, Caleb James DeLisle skrev:
Bug Vincent or Sergiu, I don't have power to let you see it.
The only proposed solution is allow only permissions given the user and the
author (your plan).
Andreas Jonsson wrote:
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? 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
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.
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.
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?
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.
Yes.
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.
There are other cases where an object should have different permissions than
the document containing it.
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"
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.
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
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".
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.
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.
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.
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:02 p.m.
It is great to see more people getting involved in improving security.
On 05/26/2010 09:39 AM, 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.
<snip>
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.
There is actually a similar idea that was already mentioned in IRC
AFAIR. The idea is to block scripts that require high privileges, until
an administrator reviews the code and explicitly gives the scripts the
rights they need to have. This would be done using an administrative
interface that lists all scripts and gives a way to allow/deny the
rights for them.
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.)
How can it be misused if the rights of the user are checked too? If the
script attempts to access another document, which content the user is
not allowed to see, the attempt would just fail.
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.
IMO using scripts in comments should be completely forbidden, I don't
see any use for scripts there.
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."
In this case, scripts would have no rights by default, unless the user
resaves the document with "programmer" set. What is the purpose of
saving the scripts then? If anyone can make their script run (with less
privileges, but run) by setting a check box, clicking away the warning
and giving the password, this would be just seen as an additional
annoyance by the normal users.
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.
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.
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.
9. Fix all applications that undoubtly will be broken by this change.
This is the hardest part. If the migration will be a pain and will take
days to complete, nobody will do it. We should really detect what is
broken and why, and have a nice interface that helps to migrate (and
ideally automatically migrates what possible).
Do you other people agree with me when I say that the
security model
must be replaced immediately?
Replaced - yes, but not immediately. There are other
not less important
issues that should be fixed too, and this particular one will take a lot
of time and break a lot of things. I think it is better to take some
time and make the transition smoother, while working on other urgent
issues too.
What do you think about my suggestion?
Please, poke at it to try to find any attacks that I have not
thought of.
Have you thought about inclusion of documents and scripts in each other?
How would you calculate the rights in such case?
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.
A proof of concept would be great.
Regards,
Alex
Best regards,
Andreas Jonsson
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5227
days inactive
5227
days old
5 comments
3 participants
participants (3)
-
Alex Busenius -
Andreas Jonsson -
Caleb James DeLisle