26 May
2010
26 May
'10
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