Hi, We're using UUIDs a lot, and it's pretty painful that they are security proxied. They're in the standard library from python 2.5 (http://docs.python.org/library/uuid.html) and are immutable according to the documentation. I think they meet all the all the requirements to be rocks. So unless someone complains, I'll commit the attached patch in a few days. -- Brian Sutherland
On Apr 3, 2009, at 2:57 AM, Brian Sutherland wrote:
Hi,
We're using UUIDs a lot, and it's pretty painful that they are security proxied. They're in the standard library from python 2.5 (http://docs.python.org/library/uuid.html) and are immutable according to the documentation.
"According to the documentation" isn't good enough.
I think they meet all the all the requirements to be rocks. So unless someone complains, I'll commit the attached patch in a few days.
u = uuid.UUID('{12345678-1234-5678-1234-567812345678}') u.__dict__['int'] = 1 u UUID('00000000-0000-0000-0000-000000000001')
This isn't exactly immutable. The protection system would prevent this sort of mutation, but I'm still nervous about a rock implemented in Python. We have to be darn sure that there isn't some sort of loop hole here. Really we have to do this with any rock and I'm not sure we have the formalisms necessary to guide this. Oh wait:
del u.int u Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/python/2.5.1/lib/python2.5/uuid.py", line 192, in __repr__ return 'UUID(%r)' % str(self) File "/usr/local/python/2.5.1/lib/python2.5/uuid.py", line 198, in __str__ hex = '%032x' % self.int AttributeError: 'UUID' object has no attribute 'int'
Oops. This would not be prevented by the protection system. -1 for making uuids rocks. Jim -- Jim Fulton Zope Corporation
Hi there, One fundamental question about this that I have is why we want to protect the user against such loopholes anyway? Isn't zope.security a protection system against *accidental* mistakes in building secure applications? I.e. I call a method and then I find out I have no such access. Do we really need to protect the developer against more arcane workarounds? If I *want* to work around the security system deliberately I can simply remove the security proxy and be done with it. It's not like the system is protecting against this anyway. Protecting against workarounds is useful if you allow through the web manipulation of code itself. But who is actually doing this? Regards, Martijn
On Apr 10, 2009, at 9:25 AM, Martijn Faassen wrote:
Hi there,
One fundamental question about this that I have is why we want to protect the user against such loopholes anyway?
Isn't zope.security a protection system against *accidental* mistakes in building secure applications?
No
I.e. I call a method and then I find out I have no such access. Do we really need to protect the developer against more arcane workarounds?
If I *want* to work around the security system deliberately I can simply remove the security proxy and be done with it. It's not like the system is protecting against this anyway.
Protecting against workarounds is useful if you allow through the web manipulation of code itself. But who is actually doing this?
The purpose of the protection system is to protect an application against untrusted code provided by people other than the application develoer. If an application has no untrusted code, then the protection system isn't necessary. I'll guess that 99% of applications don't support untrusted code and don't need the Zope protection system(s). The applications people build with Grok probably fall in this category, or one would hope. :) There are some applications, such as Zope 2, Plone, and many of our (ZC's) applications that support untrusted code and, for these systems, the protection system is critical. It doesn't protect the application developer from herself, it protects her from the people writing the untrusted code. (Note that, in some ways, HTTP requests represent untrusted code. This case can often be handled by simple resource-protection schemes, although some applications can still benefit from the Zope 3 protection scheme, which can help mediate access to content when fine- grained control is needed.) Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote:
On Apr 10, 2009, at 9:25 AM, Martijn Faassen wrote: [snip]
Protecting against workarounds is useful if you allow through the web manipulation of code itself. But who is actually doing this?
The purpose of the protection system is to protect an application against untrusted code provided by people other than the application develoer. If an application has no untrusted code, then the protection system isn't necessary. I'll guess that 99% of applications don't support untrusted code and don't need the Zope protection system(s). The applications people build with Grok probably fall in this category, or one would hope. :)
There are some applications, such as Zope 2, Plone, and many of our (ZC's) applications that support untrusted code and, for these systems, the protection system is critical. It doesn't protect the application developer from herself, it protects her from the people writing the untrusted code.
I know that Plone is moving away from untrusted code, and Zope 2 isn't using zope.security anyway. That leaves ZC's applications, which I imagine are based on zope.security?
(Note that, in some ways, HTTP requests represent untrusted code. This case can often be handled by simple resource-protection schemes, although some applications can still benefit from the Zope 3 protection scheme, which can help mediate access to content when fine- grained control is needed.)
I take it that zope.security is supporting three use cases: a) prevent an application developer for making mistakes concerning security, or alternatively, forcing developers to think about security in-depth. b) prevent someone from viewing something with a public view because they don't have access to content-level methods and attributes. (which I take is your "HTTP request as untrusted code" scenario). (alternate strategies are Grok's, which has view-level security but allows content-level declarations about what's accessible or not. But prominent Grok users are clamoring for something closer to the traditional approach with real content level protections) c) allow Python/template untrusted code As far as I now know, the only actual applications of zope.security to accomplish c) are ZC's. a) and b) would be served well enough if zope.security only cared about preventing accidental security violations. If this is correct, this is interesting; we are taking on a burden for a rather limited set of use cases. Unfortunately these are ZC's use cases. Would there be a way to isolate these use cases so that other users in the community did not have to worry about this anymore? I ask because the topic has come up a few times already (now, and with the Python-based i18n message ids a while back). It could be that c) grows more important again over time in case of a "rebirth of the ZMI", but that doesn't look like it's about to happen any time soon. And if it does it might happen in a more limited way that doesn't require a sophisticated untrusted code infrastructure. Regards, Martijn
On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote: ...
I know that Plone is moving away from untrusted code,
I predict they won't, but we'll see.
and Zope 2 isn't using zope.security anyway.
That's immaterial. I was talking about the use case.
That leaves ZC's applications, which I imagine are based on zope.security?
Yes, not that it is really relevant to the discussion.
(Note that, in some ways, HTTP requests represent untrusted code. This case can often be handled by simple resource-protection schemes, although some applications can still benefit from the Zope 3 protection scheme, which can help mediate access to content when fine- grained control is needed.)
I take it that zope.security is supporting three use cases:
a) prevent an application developer for making mistakes concerning security,
Yes
or alternatively, forcing developers to think about security in-depth.
That is obviously not a goal. No one is forcing anyone to do anything. You don't have to use zope.security.
b) prevent someone from viewing something with a public view because they don't have access to content-level methods and attributes. (which I take is your "HTTP request as untrusted code" scenario).
It is an example of that scenario, yes.
(alternate strategies are Grok's, which has view-level security but allows content-level declarations about what's accessible or not. But prominent Grok users are clamoring for something closer to the traditional approach with real content level protections)
Interesting. Note that Zope 3's protection system addresses this case while Zope 2's system doesn't. This is one of the reasons I'd like to see Zope 2 move to the Zope 3 protection system.
c) allow Python/template untrusted code
Yes. This is where proper handling of "rocks" is most important.
As far as I now know, the only actual applications of zope.security to accomplish c) are ZC's.
I'm sure there are others. Zope 2's protection scheme addresses this use case as well, although not as well.
a) and b) would be served well enough if zope.security only cared about preventing accidental security violations.
I'm not sure what you mean by "accidental" here, but I suspect I disagree. I would agree that handling of rocks is far less important in this context.
If this is correct, this is interesting; we are taking on a burden for a rather limited set of use cases.
What burden? The protection system benefits all the use cases. It's also a burden that is easily removed if you don't have these use cases.
Unfortunately these are ZC's use cases.
They are not just ZC's use cases.
Would there be a way to isolate these use cases so that other users in the community did not have to worry about this anymore? I ask because the topic has come up a few times already (now, and with the Python-based i18n message ids a while back).
Sure. If you (think you) don't need a protection system, or think you can design a lighter weight one that meets your needs, then don't use zope.security. By far, most of the pain of Zope 3 protection system, as well as it's power, comes from the use of security proxies. The handling of rocks is a minor issue. It's worth noting that applications that don't allow untrusted code (other than the request) but that still want to use the protection system to protect content can can be much more liberal about what is treated as a rock by declaring rock classes themselves. The mechanisms support this now, although there may not be an API. Jim -- Jim Fulton Zope Corporation
On Friday 10 April 2009, Jim Fulton wrote:
Unfortunately these are ZC's use cases.
They are not just ZC's use cases.
Keas is relying on that safety heavily too. Anyone who wants to build a secure DSL based on Python really wants zope.security. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Friday 10 April 2009, Jim Fulton wrote:
Unfortunately these are ZC's use cases. They are not just ZC's use cases.
Keas is relying on that safety heavily too. Anyone who wants to build a secure DSL based on Python really wants zope.security.
Okay, second case of such usage noticed. One thing that worries me is that PyPy folks keep saying it probably isn't really secure, though they refuse to specify why not when Chris Withers tried to find out last year at EuroPython. Regards, Martijn
Martijn Faassen wrote:
Stephan Richter wrote:
On Friday 10 April 2009, Jim Fulton wrote:
Unfortunately these are ZC's use cases. They are not just ZC's use cases. Keas is relying on that safety heavily too. Anyone who wants to build a secure DSL based on Python really wants zope.security.
Okay, second case of such usage noticed.
One thing that worries me is that PyPy folks keep saying it probably isn't really secure, though they refuse to specify why not when Chris Withers tried to find out last year at EuroPython.
I suspect that's because Python allows anything by default; zope.security and RestrictedPython only provide a way to close known holes. The security model of Javascript running in a browser is very similar, though, and that seems to be good enough for most people. Shane
On Apr 10, 2009, at 3:20 PM, Shane Hathaway wrote:
Martijn Faassen wrote:
Stephan Richter wrote:
On Friday 10 April 2009, Jim Fulton wrote:
Unfortunately these are ZC's use cases. They are not just ZC's use cases. Keas is relying on that safety heavily too. Anyone who wants to build a secure DSL based on Python really wants zope.security.
Okay, second case of such usage noticed.
One thing that worries me is that PyPy folks keep saying it probably isn't really secure, though they refuse to specify why not when Chris Withers tried to find out last year at EuroPython.
I suspect that's because Python allows anything by default; zope.security and RestrictedPython only provide a way to close known holes.
Wrong in the case of zope.security. zope.security uses security proxies that only allow what is specifically allowed and deny everything else. Because zope.proxy is written in C, there's no way to defeat it in Python. The other potential holes I'm aware of are with: - rocks, which I'm very conservative with, and - __builtins__. You have to construct builtins very carefully, which we do and make sure you avoid certain problematic builtins, which we also do. It's hard to guess what they might be referring to, since they don't provide any specifics. Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote:
On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote: ....
I know that Plone is moving away from untrusted code,
I predict they won't, but we'll see.
Well, it's on the roadmap to move away from it. The use case of allowing untrusted users to add Python code TTW to the system simply doesn't exist anymore. We do have the use-case of allowing trusted people to add templates or code TTW and many other things like data level and view based security. The RestrictedPython case however is something we will gladly give up. Hanno
On Apr 10, 2009, at 11:32 AM, Hanno Schlichting wrote:
We do have the use-case of allowing trusted people to add templates or code TTW and many other things like data level and view based security. The RestrictedPython case however is something we will gladly give up.
Trusted people!? Are you checking their ID at the door? All you have in terms of trust are their credentials. You don't want to allow many, many things TTW, even if they logged in with the trusted credentials. Otherwise, you give them the same credentials on your physical machine that serves that app (e.g. they import os TTW). Finally, even if you are fine with allowing that because you trust them, who guarantees that every login with those credentials is really that trusted person? Zvezdan
Zvezdan Petkovic wrote:
On Apr 10, 2009, at 11:32 AM, Hanno Schlichting wrote:
We do have the use-case of allowing trusted people to add templates or code TTW and many other things like data level and view based security. The RestrictedPython case however is something we will gladly give up.
Trusted people!? Are you checking their ID at the door?
All you have in terms of trust are their credentials.
Sure, that's called authentication. Happens to be the same in any technical or physical world.
You don't want to allow many, many things TTW, even if they logged in with the trusted credentials.
We are in the business of content management. The most valuable information the system and the entire physical machine has is the content in the system. You don't run web applications on any kind of shared servers where the system has any more valuable data. A person who is allowed to steal or delete the entire content is what I call trusted. The potential additional damage of that person breaking out of the web application is a minor concern compared to this. Allowing any kind of TTW development is always going to be an explicit opt-in, but if you are willing to allow this, we won't try to stop you with limited access anymore. Hanno
On Apr 10, 2009, at 12:31 PM, Hanno Schlichting wrote:
We are in the business of content management. The most valuable information the system and the entire physical machine has is the content in the system. You don't run web applications on any kind of shared servers where the system has any more valuable data.
A person who is allowed to steal or delete the entire content is what I call trusted. The potential additional damage of that person breaking out of the web application is a minor concern compared to this. Allowing any kind of TTW development is always going to be an explicit opt-in, but if you are willing to allow this, we won't try to stop you with limited access anymore.
So, it's quite black and white. I would argue that there are several classes of users. At least these: 1. Trusted users inside your organization that makes the software.The role they get through their credentials has highest trust level and they could be allowed to do the most TTW. 2. Trusted users inside your customer organization. Those are usually the techies in the customer organization who configure your software to run the way they want. The role they get through their credentials has some trust level. They can change certain things TTW. 3. Untrusted users in your customer organization. These users get a role through their credentials that allows them to configure the software parts, but cannot do any TTW changes. 4. Untrusted customers of your customer organization. Plain web users. They just view the content. The granularity levels can be even finer between 1, 2, and 3 above. This allows for various shades of grey. However, since anybody's credentials can be stolen, I do not want to allow rock changes and arbitrary imports even to the users in class 1 above. Because: 1. they have the highest trust level in that web app, but 2. they are just an ordinary user on a machine running that web app, and 3. there are people who have higher credentials on that machine -- sysadmins. That's why leaving zope.security safer by default is the right thing. If you want to allow more, wrap around it someorg.lesssecurity or even someorg.nosecurity. Zvezdan
Hey, Jim Fulton wrote:
On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote:
and Zope 2 isn't using zope.security anyway.
That's immaterial. I was talking about the use case.
It's hard to tell whether Zope 2 will ever adopt zope.security to fulfill this use case - I have the impression the big apps are trying to move away from Zope 2, and Plone at least seems to be moving away from untrusted code. I think that's interesting in figuring out where we can and cannot go with zope.security. [snip]
I take it that zope.security is supporting three use cases:
a) prevent an application developer for making mistakes concerning security,
Yes
or alternatively, forcing developers to think about security in-depth.
That is obviously not a goal. No one is forcing anyone to do anything. You don't have to use zope.security.
Some systems come with zope.security out of the box, such as traditional Zope 3, meaning normal development with it forces developers to think about this. I'm not saying this is a bad thing; it is a different perspective on "preventing an application developer from making mistakes".
b) prevent someone from viewing something with a public view because they don't have access to content-level methods and attributes. (which I take is your "HTTP request as untrusted code" scenario).
It is an example of that scenario, yes.
Do you have other examples? [snip]
c) allow Python/template untrusted code
Yes. This is where proper handling of "rocks" is most important.
As far as I now know, the only actual applications of zope.security to accomplish c) are ZC's.
I'm sure there are others.
Yes, as Stephan said, Keas.
Zope 2's protection scheme addresses this use case as well, although not as well.
a) and b) would be served well enough if zope.security only cared about preventing accidental security violations.
I'm not sure what you mean by "accidental" here, but I suspect I disagree. I would agree that handling of rocks is far less important in this context.
Okay, let's just agree on the latter. :) [snip]
Would there be a way to isolate these use cases so that other users in the community did not have to worry about this anymore? I ask because the topic has come up a few times already (now, and with the Python-based i18n message ids a while back). [snip] It's worth noting that applications that don't allow untrusted code (other than the request) but that still want to use the protection system to protect content can can be much more liberal about what is treated as a rock by declaring rock classes themselves. The mechanisms support this now, although there may not be an API.
This is what I was aiming at. Would it be possible to have a zope.sandbox that builds on zope.security that does the whole untrusted execution thing, and then we have another profile of zope.security that just allows everything considered immutable as rocks? Can such things exist in parallel in the same code base? I'm not saying that if so, we're going to do the work immediately. I just want to explore what directions we could go in if someone does want to do the work. People trying to port zope.security dependent code to the google app engine seem to have yet another use case. This is fulfilled right now by a hacked up fork that at least makes import works, even though none of the actual functionality is there. We might want to put a knob in zope.security to support this hack out of the box too. Regards, Martijn
On Apr 10, 2009, at 12:26 PM, Martijn Faassen wrote: ...
b) prevent someone from viewing something with a public view because they don't have access to content-level methods and attributes. (which I take is your "HTTP request as untrusted code" scenario).
It is an example of that scenario, yes.
Do you have other examples?
The view doesn't have to be public. For example, the view might only be accessible to people with a particular role, and you might further limit what they can do based on the data they can access. ...
It's worth noting that applications that don't allow untrusted code (other than the request) but that still want to use the protection system to protect content can can be much more liberal about what is treated as a rock by declaring rock classes themselves. The mechanisms support this now, although there may not be an API.
This is what I was aiming at. Would it be possible to have a zope.sandbox that builds on zope.security that does the whole untrusted execution thing, and then we have another profile of zope.security that just allows everything considered immutable as rocks? Can such things exist in parallel in the same code base?
I don't see the point of a separate package. This is a very small corner of zope.security. A simple API for extending the definition of rocks would be enough to deal with this particular issue. Note that "considered immutable" is rather vague. UUIDs aren't immutable if you're willing to be only slightly devious. But if you aren't worried about that in an application, then that isn't a problem. You might even choose to make truly mutable objects into rocks if you know your application is going to play nice. ...
People trying to port zope.security dependent code to the google app engine seem to have yet another use case. This is fulfilled right now by a hacked up fork that at least makes import works, even though none of the actual functionality is there. We might want to put a knob in zope.security to support this hack out of the box too.
Or tell them to use something else altogether. It all depends on their use cases. If they want a seatbelt rather than a space suit, I suppose a python-based proxy could be good enough, although it would likely be too slow for that environment. Jim -- Jim Fulton Zope Corporation
Hey, Jim Fulton wrote: [snip]
I don't see the point of a separate package. This is a very small corner of zope.security.
Sure, it could be solved within zope.security as well.
A simple API for extending the definition of rocks would be enough to deal with this particular issue.
Note that "considered immutable" is rather vague. UUIDs aren't immutable if you're willing to be only slightly devious. But if you aren't worried about that in an application, then that isn't a problem. You might even choose to make truly mutable objects into rocks if you know your application is going to play nice.
Right, I meant "considered immutable" in the dynamically typed sense. I can make classes that I consider to be immutable after creation in Python, even though I don't actually enforce it by preventing people from setting attributes on them.
People trying to port zope.security dependent code to the google app engine seem to have yet another use case. This is fulfilled right now by a hacked up fork that at least makes import works, even though none of the actual functionality is there. We might want to put a knob in zope.security to support this hack out of the box too.
Or tell them to use something else altogether. It all depends on their use cases. If they want a seatbelt rather than a space suit, I suppose a python-based proxy could be good enough, although it would likely be too slow for that environment.
The use case appears to be to use code that depends on zope.security on the google app engine. We have quite few libraries that do that out there. I think they just simply hack the proxy creation out completely, meaning that zope.security is basically a no-op. I asked what exactly is going on in another thread, so we just wait until we find out. :) Regards, Martijn
Martijn Faassen wrote:
b) prevent someone from viewing something with a public view because they don't have access to content-level methods and attributes. (which I take is your "HTTP request as untrusted code" scenario). (alternate strategies are Grok's, which has view-level security but allows content-level declarations about what's accessible or not. But prominent Grok users are clamoring for something closer to the traditional approach with real content level protections)
Well, I like the idea of always having a back-stop on an object that says "I won't allow you to access bits of the current object that the user I currently think you're representing isn't allowed to access". Stopping caring about rocks so much makes that no longer the case. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Martijn Faassen wrote:
Isn't zope.security a protection system against *accidental* mistakes in building secure applications? I.e. I call a method and then I find out I have no such access. Do we really need to protect the developer against more arcane workarounds?
Yes, that's its stated aim, and I want to rely on that, so I care a lot.
If I *want* to work around the security system deliberately I can simply remove the security proxy and be done with it. It's not like the system is protecting against this anyway.
Well, not if you don't have access to that removal code. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (8)
-
Brian Sutherland -
Chris Withers -
Hanno Schlichting -
Jim Fulton -
Martijn Faassen -
Shane Hathaway -
Stephan Richter -
Zvezdan Petkovic