Re: [Python-Dev] new security doc using object-capabilities
On 9/6/06, Ka-Ping Yee [EMAIL PROTECTED] wrote: Hi Brett,Here are some comments on your proposal.Sorry this took so long.I apologize if any of these comments are out of date (but also lookforward to your answers to some of the questions, as they'll help me understand some more of the details of your proposal).Thanks!I think they are slightly outdated. The latest version of the doc is in the bcannon-objcap branch and is named securing_python.txt ( http://svn.python.org/view/python/branches/bcannon-objcap/securing_python.txt ). Introduction ///[...] Throughout this document several terms are going to be used.A sandboxed interpreter is one where the built-in namespace is not the same as that of an interpreter whose built-ins were unaltered, which is called an unprotected interpreter.Is this a definition or an implementation choice?As in, are youdefining sandboxed to mean with altered built-ins or just restricted in some way, and does the above mean to imply thataltering the built-ins is what triggers other kinds of restrictions(as it did in Python's old restricted execution mode)? There is no triggering of other restrictions. This is an implementation choice. Sandboxed means with altered built-ins. A bare interpreter is one where the built-in namespace has been stripped down the bare minimum needed to run any form of basic Python program.This means that all atomic types (i.e., syntactically supported types), ``object``, and the exceptions provided by the ``exceptions`` module are considered in the built-in namespace.There have also been no imports executed in the interpreter. Is a bare interpreter just one example of a sandboxed interpreter,or are all sandboxed interpreters in your design initially bare (i.e.sandboxed = bare + zero or more granted authorities)? You build up from a bare interpreter by adding in authorities (e.g., providing a wrapped version of open()) to reach the level of security you want. The security domain is the boundary at which security is cared about.For this dicussion, it is the interpreter.It might be clearer to say (if i understand correctly) Each interpreter is a separate security domain.Many interpreters can run within a single operating system process, right?Yes. Could you say a bit about what sort of concurrency model you have in mind?None specifically. Each new interpreter automatically runs in its own Python thread, so they have essentially the same concurrency as using the 'thread' module. How would this interact (if at all) with use of theexisting threading functionality?See above. The powerbox is the thing that possesses the ultimate power in the system.In our case it is the Python process.This could also be the application process, right?If Python is embedded, yes. Rationale ///[...] For instance, think of an application that supports a plug-in system with Python as the language used for writing plug-ins.You do not want to have to examine every plug-in you download to make sure that it does not alter your filesystem if you can help it.With a proper security model and implementation in place this hinderance of having to examine all code you execute should be alleviated.I'm glad to have this use case set out early in the document, so thereader can keep it in mind as an example while reading about the model. Approaches to Security /// There are essentially two types of security: who-I-am (permissions-based) security and what-I-have (authority-based) security.As Mark Miller mentioned in another message, your descriptions ofwho-I-am security and what-I-have security make sense, butthey don't correspond to permission vs. authority.They correspond to identity-based vs. authority-based security.Right. This was fixed the day Mark and Alan Karp made the comment. Difficulties in Python for Object-Capabilities //[...] Three key requirements for providing a proper perimeter defence is private namespaces, immutable shared state across domains, and unforgeable references.Nice summary. Problem of No Private Namespace ===[...] The Python language has no such thing as a private namespace.Don't local scopes count as private namespaces?It seems clearthat they aren't designed with the intention of being exposed,unlike other namespaces in Python. Sort of. But you can still get access to them if you have an execution frame and they are not persistent. Generators are are worse since they store their execution frame with the generator itself, completely exposing the local namespace. It also makes providing security at the object level using object-capabilities non-existent in pure Python code. I don't think this is necessarily the case.No Python code i've ever seen expects to be able to invade the local scopes of other functions, so you could use them as private namespaces.Thereare two ways i've
Re: [Python-Dev] new security doc using object-capabilities
Hi Brett, Here are some comments on your proposal. Sorry this took so long. I apologize if any of these comments are out of date (but also look forward to your answers to some of the questions, as they'll help me understand some more of the details of your proposal). Thanks! Introduction /// [...] Throughout this document several terms are going to be used. A sandboxed interpreter is one where the built-in namespace is not the same as that of an interpreter whose built-ins were unaltered, which is called an unprotected interpreter. Is this a definition or an implementation choice? As in, are you defining sandboxed to mean with altered built-ins or just restricted in some way, and does the above mean to imply that altering the built-ins is what triggers other kinds of restrictions (as it did in Python's old restricted execution mode)? A bare interpreter is one where the built-in namespace has been stripped down the bare minimum needed to run any form of basic Python program. This means that all atomic types (i.e., syntactically supported types), ``object``, and the exceptions provided by the ``exceptions`` module are considered in the built-in namespace. There have also been no imports executed in the interpreter. Is a bare interpreter just one example of a sandboxed interpreter, or are all sandboxed interpreters in your design initially bare (i.e. sandboxed = bare + zero or more granted authorities)? The security domain is the boundary at which security is cared about. For this dicussion, it is the interpreter. It might be clearer to say (if i understand correctly) Each interpreter is a separate security domain. Many interpreters can run within a single operating system process, right? Could you say a bit about what sort of concurrency model you have in mind? How would this interact (if at all) with use of the existing threading functionality? The powerbox is the thing that possesses the ultimate power in the system. In our case it is the Python process. This could also be the application process, right? Rationale /// [...] For instance, think of an application that supports a plug-in system with Python as the language used for writing plug-ins. You do not want to have to examine every plug-in you download to make sure that it does not alter your filesystem if you can help it. With a proper security model and implementation in place this hinderance of having to examine all code you execute should be alleviated. I'm glad to have this use case set out early in the document, so the reader can keep it in mind as an example while reading about the model. Approaches to Security /// There are essentially two types of security: who-I-am (permissions-based) security and what-I-have (authority-based) security. As Mark Miller mentioned in another message, your descriptions of who-I-am security and what-I-have security make sense, but they don't correspond to permission vs. authority. They correspond to identity-based vs. authority-based security. Difficulties in Python for Object-Capabilities // [...] Three key requirements for providing a proper perimeter defence is private namespaces, immutable shared state across domains, and unforgeable references. Nice summary. Problem of No Private Namespace === [...] The Python language has no such thing as a private namespace. Don't local scopes count as private namespaces? It seems clear that they aren't designed with the intention of being exposed, unlike other namespaces in Python. It also makes providing security at the object level using object-capabilities non-existent in pure Python code. I don't think this is necessarily the case. No Python code i've ever seen expects to be able to invade the local scopes of other functions, so you could use them as private namespaces. There are two ways i've seen to invade local scopes: (a) Use gc.get_referents to get back from a cell object to its contents. (b) Compare the cell object to another cell object, thereby causing __eq__ to be invoked to compare the contents of the cells. So you could protect local scopes by prohibiting these or by simply turning off access to func_closure. It's clear that hardly any code depends on these introspection featuresl, so it would be reasonble to turn them off in a sandboxed interpreter. (It seems you would have to turn off some introspection features anyway in order to have reliable import guards.) Problem of Mutable Shared State === [...] Regardless, sharing of state that can be influenced by another interpreter is not safe for object-capabilities. Yup. Threat Model /// Good to see this specified here. I like the way you've broken
Re: [Python-Dev] new security doc using object-capabilities
Phillip J. Eby wrote: And what about code that needs to pass on a subset of a capability? With one object == one capability, there is no such thing as a subset of a capability -- the capabilities are the atomic units at which you control access. So you need to make them fine-grained enough to begin with. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote: On 7/23/06, Phillip J. Eby mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: one proxy plus one namechecker equals one capability. In other words, you could take the restricted interpreter, the proxy mechanism, and the namechecker and leave most of the rest alone, and you'd have your capability system. Then you could focus more time and attention on the parts of the problem that Zope *doesn't* solve, instead of reinventing the ones that it already does. Right, but I am trying to remove the need for a namechecker which makes it an object-capabilities system. As I said above: a namechecker plus a proxy *equals* an object capability. When I say name checker I mean the Zope type that allows you to specify a list of names that are allowed for a given object. This allowing is not based on identity or code signing or anything like that. It's just a list of attribute names: i.e. a capability mask over an existing object. When you create a proxy using this name mask, that proxy becomes a capability that allows access to the given names on the underlying object. I like the fundemental design difference of object-capabilities It's not a difference at all, let alone a fundamental one. Zope just happens to allow other kinds of security checking *in addition to* capabilities, if you want them. However, most of its more basic encapsulation features are 100% capability based. Meanwhile, if you want to implement an object-capability system, you will need something that is basically a mask, to allow one piece of code to create capabilities that can be given to another. What you end up with for doing that is going to look almost exactly like a Zope proxy plus a Zope name checker. I hate to harp on this point, but there seems to be a trend that when people have capabilities on their mind, they tend to look at Zope and dismiss it as not being capability-based, when in fact Zope's approach is capabilities *plus* other things. (Of course, most of those other things have to do with closing holes like __subclasses__, while improving performance by still allowing lots of common objects not to be proxied.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
On 7/23/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote:When I say name checker I mean the Zope type that allows you to specify alist of names that are allowed for a given object.This allowing is not based on identity or code signing or anything like that.It's just a listof attribute names: i.e. a capability mask over an existing object.When you create a proxy using this name mask, that proxy becomes a capability that allows access to the given names on the underlying object.OK, then using the term namechecker through me off. I like the fundemental design difference of object-capabilitiesIt's not a difference at all, let alone a fundamental one.Zope justhappens to allow other kinds of security checking *in addition to*capabilities, if you want them.However, most of its more basic encapsulation features are 100% capability based.Meanwhile, if you want to implement an object-capability system, you will need something that is basically a mask, to allow one piece of code tocreate capabilities that can be given to another.What you end up with fordoing that is going to look almost exactly like a Zope proxy plus a Zope name checker.I hate to harp on this point, but there seems to be a trend that when people have capabilities on their mind, they tend to look at Zope anddismiss it as not being capability-based, when in fact Zope's approach iscapabilities *plus* other things.Well, Jim said that Zope proxies didn't conform to the strict definition of object-capabilities the last time this all came about: http://mail.python.org/pipermail/python-dev/2003-March/033884.html and http://mail.python.org/pipermail/python-dev/2003-March/033915.html . He said they *could* be made to be what object-capabilities is defined as, but they were not currently structured that way. Those comments are one of the reasons I never considered thinking of Zope proxies as a object-capabilities system. (Of course, most of those other things have to do with closing holes like __subclasses__, while improving performance by still allowing lots ofcommon objects not to be proxied.)OK, then I need something clarified. If you read http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies , it talks about creating the proxies. I get they restrict attribute access and wrap all returned objects in proxies themselves (unless they are considered safe). But to judge whether an attribute should be returned, it checks the security context. It also mentions how access to the security policy must be available so that proper security checks can be done to either grant or deny access. So what I want to know is if this security context is this global thing that proxies access every time to check whether something is allowed or not. Or is it a per-object specification? And what is the security domain for Zope proxies; objects, interpreter, running Python program, what? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Brett Cannon wrote: On 7/23/06, *Armin Rigo* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Also, I hate to sound self-centered, but I should point out somewhere that PyPy was started by people who no longer wanted to maintain a fork of CPython, and preferred to work on building CPython-like variants automatically. Many of the security features you list would be quite easier to implement and maintain in PyPy than CPython -- also from a security perspective: it is easier to be sure that some protection is complete, and remains complete over time, if it is systematically generated instead of hand-patched in a dozen places. It doesn't sound self-centered. =) Problem is that my knowledge base is obviously all in CPython so my startup costs are much lower than if I tried this in PyPy. Plus there is the point of embedding this into Firefox (possibly) eventually. Does PyPy support embedding yet at the C level? Another rationale for basing the work on CPython is that it should be possible to implement the resulting security model regardless of the implementation language used for the interpreter core (C/Python, Java/Python, C#/Python, RPython/Python). If you can figure out how to do it in C, it should be feasible to do it in the others. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
At 12:50 AM 7/24/2006 -0700, Brett Cannon wrote: OK, then I need something clarified. If you read http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxieshttp://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies , it talks about creating the proxies. I get they restrict attribute access and wrap all returned objects in proxies themselves (unless they are considered safe). But to judge whether an attribute should be returned, it checks the security context. That depends on the checker. The proxy implementation delegates all access decisions to a checker object. Some checkers check permissions, but a NamesChecker just checks a statically-defined list of names. It also mentions how access to the security policy must be available so that proper security checks can be done to either grant or deny access. So what I want to know is if this security context is this global thing that proxies access every time to check whether something is allowed or not. Proxies don't do that; checkers do. The default Checker implementation doesn't even look at a security context if a name is declared public (i.e., it's a NamesChecker). Look at the zope.security.checker module for details. IOW, to make it a pure capabilities system, you would only *delete* code, not add any, as far as I can tell. Or is it a per-object specification? Each proxy can have its own checker, but an individual checker instance can be shared between proxies. And what is the security domain for Zope proxies; objects, interpreter, running Python program, what? There are restricted eval and exec operations to run restricted code. The primary language limitations imposed are the lack of eval/exec by the restricted code, and lack of support for raise and try/except. Implementing these would require additional compiler hacking to add code to ensure that e.g. tracebacks get wrapped. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
At 12:04 PM 7/25/2006 +1200, Greg Ewing wrote: Phillip J. Eby wrote: When I say name checker I mean the Zope type that allows you to specify a list of names that are allowed for a given object. This allowing is not based on identity or code signing or anything like that. It's just a list of attribute names: i.e. a capability mask over an existing object. But this is backwards from what a true object-capability system should be like if it's properly designed. Instead of starting with too-powerful objects and trying to hide some of their powers, the different powers should be separated into different objects in the first place. And what about code that needs to pass on a subset of a capability? You need the ability to create such capability-restricted subsets anyway, no matter how pure a system you start with. And being able to create capability masks for existing objects means you don't have to redesign every piece of code ever written for Python to make it secure. It sounds to me like Zope is using the approach it's using because it's having to work with Python as it currently is, not because its approach is the best one. Well, that depends a lot on how you define best. Practicality beats purity, doesn't it? ;) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Phillip J. Eby wrote: At 12:04 PM 7/25/2006 +1200, Greg Ewing wrote: Phillip J. Eby wrote: When I say name checker I mean the Zope type that allows you to specify a list of names that are allowed for a given object. This allowing is not based on identity or code signing or anything like that. It's just a list of attribute names: i.e. a capability mask over an existing object. But this is backwards from what a true object-capability system should be like if it's properly designed. Instead of starting with too-powerful objects and trying to hide some of their powers, the different powers should be separated into different objects in the first place. And what about code that needs to pass on a subset of a capability? You need the ability to create such capability-restricted subsets anyway, no matter how pure a system you start with. That is true, but doing so for every secure object has significant costs. A simple wrapper is not sufficient, because it would not prevent a wrapped object from returning a reference to itself, bypassing the wrapper. To solve this problem you need to use the more complex Membrane pattern, which also wraps the results of method calls on a wrapped object, for example. In fact Zope's approach does implement a membrane, but this does not really dent the argument that Greg Ewing was making. A pure capability system incurs the complexity and performance costs of wrappers or membranes only in cases where they are needed, not for every object, and the complexity is only in user code, not in the system's security kernel. -- David Hopwood [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Hi Brett, On Sat, Jul 22, 2006 at 10:33:19AM -0700, Brett Cannon wrote: Thanks for the link, Armin. Since you guys don't have the import restrictions the CPython version would have and just have different coding needs for RPython obviously I can't just do a blind copy. But I will definitely take a look as I develop. Maybe you guys can even help to lower the duplication if it makes sense for you. Yes, it should be possible to abstract the common logic in some way, using some kind of interface for all OS inspection and 'sys.modules' manipulations. BTW, do you guys happen to have extra tests from import? Yes, there is http://codespeak.net/svn/pypy/dist/pypy/module/__builtin__/test/test_import.py which will also need a bit of rewriting, but that should be straightforward. A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Hi David, hi Brett, On Sun, Jul 23, 2006 at 02:18:48AM +0100, David Hopwood wrote: If I understand correctly, the proposal is that any incompatible changes to the language would apply only in sandboxed interpreters. So there is no reason why support for these couldn't go into the main branch. That's what I originally thought too, but Brett writes: Implementation Details An important point to keep in mind when reading about the implementation details for the security model is that these are general changes and are not special to any type of interpreter, sandboxed or otherwise. That means if a change to a built-in type is suggested and it does not involve a proxy, that change is meant Python-wide for *all* interpreters. So that's why I'm starting to worry that Brett is proposing to change the regular Python language too. However, Brett, you also say somewhere else that backward compatibility is not an issue. So I'm a bit confused actually... Also, I hate to sound self-centered, but I should point out somewhere that PyPy was started by people who no longer wanted to maintain a fork of CPython, and preferred to work on building CPython-like variants automatically. Many of the security features you list would be quite easier to implement and maintain in PyPy than CPython -- also from a security perspective: it is easier to be sure that some protection is complete, and remains complete over time, if it is systematically generated instead of hand-patched in a dozen places. A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
On 7/23/06, Armin Rigo [EMAIL PROTECTED] wrote: Hi David, hi Brett,On Sun, Jul 23, 2006 at 02:18:48AM +0100, David Hopwood wrote: If I understand correctly, the proposal is that any incompatible changes to the language would apply only in sandboxed interpreters. So there is no reason why support for these couldn't go into the main branch.That's what I originally thought too, but Brett writes:Implementation DetailsAn important point to keep in mind when reading about the implementation details for the security model is that these aregeneral changes and are not special to any type of interpreter,sandboxed or otherwise.That means if a change to a built-in type is suggested and it does not involve a proxy, that change is meantPython-wide for *all* interpreters.So that's why I'm starting to worry that Brett is proposing to changethe regular Python language too. Yes, I am proposing changing some constructors and methods on some built-in types for the regular languages. That's it. No new keywords or major semantic changes and such. If I make changes just for sandboxed interpreters it changes the general approach of the security model by then requiring an identity check to see if the interpreter is sandboxed or not. However, Brett, you also say somewhereelse that backward compatibility is not an issue.So I'm a bit confused actually...Since this is my Ph.D. dissertation first and foremost, I am not going to tie my hands in such a way that I have to make too much of a compromise in order for this to work. I obviously don't want to change the feel of Python, but if I have to remove the constructor for code objects to prevent evil bytecode or __subclasses__() from object to prevent poking around stuff, then so be it. For this project, security is trumpeting backwards-compatibility when the latter is impossible in order to have the former. I will obviously try to minimize it, but something that works at such a basic level of the language is just going to require some changes for it to work. Also, I hate to sound self-centered, but I should point out somewherethat PyPy was started by people who no longer wanted to maintain a fork of CPython, and preferred to work on building CPython-like variantsautomatically.Many of the security features you list would be quiteeasier to implement and maintain in PyPy than CPython -- also from asecurity perspective: it is easier to be sure that some protection is complete, and remains complete over time, if it is systematicallygenerated instead of hand-patched in a dozen places.It doesn't sound self-centered. =) Problem is that my knowledge base is obviously all in CPython so my startup costs are much lower than if I tried this in PyPy. Plus there is the point of embedding this into Firefox (possibly) eventually. Does PyPy support embedding yet at the C level? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote: I obviously don't want to change the feel of Python, but if I have to remove the constructor for code objects to prevent evil bytecode or __subclasses__() from object to prevent poking around stuff, then so be it. For this project, security is trumpeting backwards-compatibility when the latter is impossible in order to have the former. I will obviously try to minimize it, but something that works at such a basic level of the language is just going to require some changes for it to work. Zope 3's sandboxing machinery manages to handle securing these things without any language changes. So, declaring it impossible to manage without backward compatibility seems inappropriate, or at least incorrect. But perhaps there is something I'm missing? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Phillip J. Eby wrote: At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote: I obviously don't want to change the feel of Python, but if I have to remove the constructor for code objects to prevent evil bytecode or __subclasses__() from object to prevent poking around stuff, then so be it. For this project, security is [trumping] backwards-compatibility when the latter is impossible in order to have the former. I will obviously try to minimize it, but something that works at such a basic level of the language is just going to require some changes for it to work. Zope 3's sandboxing machinery manages to handle securing these things without any language changes. So, declaring it impossible to manage without backward compatibility seems inappropriate, or at least incorrect. ... if Zope's sandboxing is secure. I haven't done a security review of it, but your argument assumes that it is. In any case, Zope's sandboxing is not capability-based. -- David Hopwood [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Brett Cannon wrote: On 7/23/06, Armin Rigo [EMAIL PROTECTED] wrote: Hi David, hi Brett, On Sun, Jul 23, 2006 at 02:18:48AM +0100, David Hopwood wrote: If I understand correctly, the proposal is that any incompatible changes to the language would apply only in sandboxed interpreters. So there is no reason why support for these couldn't go into the main branch. That's what I originally thought too, but Brett writes: Implementation Details An important point to keep in mind when reading about the implementation details for the security model is that these are general changes and are not special to any type of interpreter, sandboxed or otherwise. That means if a change to a built-in type is suggested and it does not involve a proxy, that change is meant Python-wide for *all* interpreters. So that's why I'm starting to worry that Brett is proposing to change the regular Python language too. Yes, I am proposing changing some constructors and methods on some built-in types for the regular languages. That's it. No new keywords or major semantic changes and such. If I make changes just for sandboxed interpreters it changes the general approach of the security model by then requiring an identity check to see if the interpreter is sandboxed or not. I assume that the extent of incompatible changes would be limited as much as possible. So the only checks would be in operations that are directly affected by whatever incompatible changes are made. The performance and complexity costs of this are likely to be small -- or at least should not be assumed to be large before having hammered out a more detailed design. Suppose, for the sake of argument, that we introduced private methods and attributes. If an attribute in an existing standard library class was changed to be private, then code depending on it would break. But if there were a notion of a compatibility private attribute that acts as private only in a sandboxed interpreter, then no code running in an unprotected interpreter would break. -- David Hopwood [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
On 7/23/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 11:07 PM 7/23/2006 +0100, David Hopwood wrote:Phillip J. Eby wrote:[snip] Brett's securing_python.txt don't refer to or cite Zope in any way, butrather relies on broad and unsupported assertions about what can or can'tbe done with Python.I hope he isn't doing the same in his thesis, as this is rather like writing about one's new theory of how to have a worldwideball-kicking contest without making any reference as to how one's theorycompares with the World Cup.The design doc is not meant to be taken as any sort of draft of my thesis. I did read that link you sent me, Philip, but it was hard to follow. So I used Google to find another reference that explained it to me much more clearly. securing_python.txt is meant to explain what I am planning to python-dev so that if someone sees some fatal flaw they can speak up and let me know, not as a thorough comparison of why my approach is better than anyone other one. I'm not saying Zope is better or worse.I'm simply saying that in abusiness context, a failure to compare and contrast a proposed build solution to show how it would be better than a well-established availablebuy solution would be called something like lack of due diligence.Ithink in the academic context it might be called something like failure to cite, but the general idea is the same, i.e., not doing your homework.:)In other words, if the solution being proposed is better than what Zopedoes, the appropriate thing in business is to show the reasons why, and the appropriate thing in science is to state a hypothesis regarding thedifferences, and then perform an experiment to either prove or disprove it.I am not going to write out a blow-by-blow comparison right now. It will come with the thesis. And I am not expecting my approach or code to be checked in blindly anyway. In any case, Zope's sandboxing is not capability-based.You're right: you haven't done a review of it.:)If you had, you'd know that one proxy plus one namechecker equals one capability.In other words,you could take the restricted interpreter, the proxy mechanism, and thenamechecker and leave most of the rest alone, and you'd have your capability system.Then you could focus more time and attention on theparts of the problem that Zope *doesn't* solve, instead of reinventing theones that it already does.Right, but I am trying to remove the need for a namechecker which makes it an object-capabilities system. Now, if Brett believes that changing the Python language is a *better* way to implement capabilities than using proxies to implement them, thengreat.His paper should explain why, and (presumably) include experimentalresults to show that they're either better or worse than Zope's approach based on some criteria.The same information is relevant to Python-Dev asto what is an appropriate approach to support sandboxing in CPython.Whatare the advantages of a built-in approach versus an add-on approach?Are there interpreter facilities that could be added to shore up any awkwardaspects of Zope's approach?(Whatever those might be.)I think people are starting to lose sight of the purpose of the doc I wrote. It was to explain what I was doing for people to see if there was any fatal flaw and to keep people updated on what I am planning on doing. It is not meant to convince anyone that my way is the best way yet. I am not even going to attempt that until I have working code. For example, one part of Zope's approach uses a custom compiler and custom builtins in order to redefine how attribute access works in certaincases.Could these customizations be replaced with options built into thePython compiler and interpreter?What improvements would that result in? Part of my point is to help alleviate the need for custom anything. Simply handwaving all of these questions away, however, with broadassertions of superiority and without even attempting to compare the newwork to Zope's existing work is really not acceptable for academia ORPython development. For the record: I have no personal interest in Zope's security system.Ididn't develop it and haven't had the need to use it, myself.I oncereviewed some of the code and offered some minor suggestions, mainly regarding performance improvement.My only axe to grind in this matter iswhat I've already stated: I think it would be crazy (in the monumentalwaste of resources sense) to consider putting *any* sandboxing system into CPython without tapping the Zope team's experiences.For example: havingimplemented such a system, what compiler or interpreter changes would'vemade the job easier?Meanwhile, what Brett does or doesn't put in his thesis is between him and his advisor, but what gets put into Python shouldn't be based on ignoringthe existing field experience and state of the art.There is no ignoring of anything. I understand their basic approach and I want to try another one. I like the fundemental design difference of object-capabilities and so I am going
Re: [Python-Dev] new security doc using object-capabilities
Hi Brett, On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote: I also plan to rewrite the import machinery in pure Python. http://codespeak.net/svn/pypy/dist/pypy/module/__builtin__/importing.py A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Re-hi, On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote: http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log. I'm not sure I understand what you propose to fix holes like constructors and __subclasses__: it seems that you want to remove them altogether (and e.g. make factory functions instead). That would completely break all programs, right? I mean, there is no way such changes would go into mainstream CPython. Or do you propose to maintain a CPython branch manually for the foreseeable future? (From experience this is a bad idea...) A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
On 7/22/06, Armin Rigo [EMAIL PROTECTED] wrote: Re-hi, On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote: http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log. I'm not sure I understand what you propose to fix holes like constructors and __subclasses__: it seems that you want to remove them altogether (and e.g. make factory functions instead).That would completely break all programs, right?Not altogether, just constructors on select types who are considered dangerous from a security standpoint. The breakage won't be horrible, but it will be there for advanced Python code. I will try to make the wording more clear when I get back to work on Tuesday.I mean, there is no way such changes would go into mainstream CPython.If this has to wait until Py3k then so be it. Or do you propose to maintain a CPython branch manually for the foreseeable future?(From experience this is a bad idea...) Yeah, not my idea of fun either, but since this is a long term project, I will at least need to for the foreseeable future. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
On 7/22/06, Armin Rigo [EMAIL PROTECTED] wrote: Hi Brett,On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote: I also plan to rewrite the import machinery in pure Python. http://codespeak.net/svn/pypy/dist/pypy/module/__builtin__/importing.pyThanks for the link, Armin. Since you guys don't have the import restrictions the CPython version would have and just have different coding needs for RPython obviously I can't just do a blind copy. But I will definitely take a look as I develop. Maybe you guys can even help to lower the duplication if it makes sense for you. BTW, do you guys happen to have extra tests from import?-Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Armin Rigo wrote: I'm not sure I understand what you propose to fix holes like constructors and __subclasses__: it seems that you want to remove them altogether (and e.g. make factory functions instead). That would completely break all programs, right? I mean, there is no way such changes would go into mainstream CPython. How much code is actually out there that uses __subclasses__? It seems like a fairly esoteric corner of the language to me. In any case, I think this approach should certainly be tried, and if it works out, considered for Py3k. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Armin Rigo wrote: Re-hi, On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote: http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log. I'm not sure I understand what you propose to fix holes like constructors and __subclasses__: it seems that you want to remove them altogether (and e.g. make factory functions instead). That would completely break all programs, right? I mean, there is no way such changes would go into mainstream CPython. If I understand correctly, the proposal is that any incompatible changes to the language would apply only in sandboxed interpreters. So there is no reason why support for these couldn't go into the main branch. Of course we want to minimize the changes that will need to be made to programs and libraries to make them work in a sandboxed interpreter, but not at the expense of security. Some incompatible changes will be necessary. -- David Hopwood [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Brett Cannon wrote: Extensible file type handling - If the file type handlers are stored in normal Python data structures as described above, it becomes feasible to make the import system extensible to different file types as well as to different file locations. Yep. Although I am more interested in restricting than broadening the file types. Either way you'd be mutating the list of recognised file types :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
That's great. I just read your draft but I have little comments to do but before let me say that I liked the idea to borrow concepts from E. I've crossed the E's path in the beginning of this year and I found it a pot of really nice ideas (for promises and capabilities). Here are my comments about the draft: - it's not really clear to me what the powerbox is. I think I got the concept of super process but maybe it's to be clarified, isn't it? It become clear in the threat model paragraph - I hope no Rubystas will read the Problem of No Private Namespace section because they have private/protected keywords to enforce this stuff :-) Writing proxies in C will slow down the dev process (altough will speed up the performance maybe) but in a far future someone will come up with an alternative closer to the Python level - Can you write down a simple example of what you mean with changing something of the built-in objects? (in Problem of mutable shared state) - What about the performance issues of the capabilities model overall? - I know what you meant to say but the paragraph about pythonicness and the security model seems a little fuzzy to me. Which are the boundaries of the allowed changes for the security stuff? - You don't say anything about networking and networked resources in the list of the standard sandboxed interpreter - Suppose we have a .py module. Based on your security model we can import it, right? When imported it generates a .pyc file. The second time we import it what happens? .pyc is ignored? import is not allowed at all? We can't rely on the name of the file.pyc because an attacker who knows the file.py is secure and the second import is done against file.pyc can replace the secure file.pyc with an implementation not secure and can do some kind of harm to the sandbox - About Filesystem information. Does the sandboxed interpreter need to know all that information about file paths, files and so on? Can't we reset those attributes to something arbitrary? - About sys module: I think the best way is to have a purged fake sys module with only the stuff you need. pypy has the concept of faked modules too (altough for a different reason) - About networking: what do you think about the E's model of really safe networking, protected remotable objects and safe RPC? Is that model applicable to Python's in some way? We can't use the E's model as a whole (ask people to generate a safe key and send it by email is unfeasible) - is the protected memory model a some kind of memory monitor system? I think that's all for the draft. I wrote these comments during the reading of the document. Hope some of these help -- Lawrence http://www.oluyede.org/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Giovanni Bajo [EMAIL PROTECTED] wrote: This recipe for safe_eval: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496746 which is otherwise very cute, does not handle this case as well: it tries to catch and interrupt long-running operations through a secondary thread, but fails on a single long operation because the GIL is not released and the alarm thread does not get its chance to run. Grin :-) You have put your finger on the Great Myth of such virtualisations, which applies to the system-level ones and even to the hardware-level ones. In practice, there is always some request that a sandbox can make to the hypervisor that can lock out or otherwise affect other sandboxes. The key is, of course, to admit that and to specify what is and is not properly virtualised, so that the consequences can at least be analysed. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Nick Maclaren wrote: This recipe for safe_eval: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496746 which is otherwise very cute, does not handle this case as well: it tries to catch and interrupt long-running operations through a secondary thread, but fails on a single long operation because the GIL is not released and the alarm thread does not get its chance to run. Grin :-) You have put your finger on the Great Myth of such virtualisations, which applies to the system-level ones and even to the hardware-level ones. In practice, there is always some request that a sandbox can make to the hypervisor that can lock out or otherwise affect other sandboxes. The key is, of course, to admit that and to specify what is and is not properly virtualised, so that the consequences can at least be analysed. I agree, and in fact Brett's work on a proper security model is greatly welcome. It's just that us mere mortals need to use eval() *now*, and that recipe is good enough for many practice uses. If you can't win, you can at least lose with dignity :) -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
For code objects, their construction is already commonly written as compile(source). For type objects, the constructor doesn't let you do anything you can't already do with a class statement. It doesn't need securing. For rewriting import.c in Python, the PEP 302 compliant import system API in pkgutil would be a good starting point. Your doc also asks about the imp.get_suffixes() list, and wonder where to set it from Python. As far as I am aware, you can't. get_suffixes() is built from _PyImport_FileTab, which is a C array. A switch statement is used to get from the file table entries to the appropriate handler functions. Quoting from the suggestions I put to the Py3k list: Use smarter data structures --- Currently, the individual handlers to load a fully identified module are exposed to Python code in a way that reflects the C-style data structures used in the current implementation. Simply switching to more powerful data structures for the file type handlers (i.e. use a PyTuple for filedescr values, a PyList for _PyImport_FileTab, and a PyDict instead of a switch statement to go from filedescr values to module loading/initialisation functions) and manipulating them all as normal Python objects could make the code in import.c much easier to follow. Extensible file type handling - If the file type handlers are stored in normal Python data structures as described above, it becomes feasible to make the import system extensible to different file types as well as to different file locations. This could be handled on a per-package basis, e.g. via a __file_types__ special attribute in packages. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
On 7/20/06, Giovanni Bajo [EMAIL PROTECTED] wrote: Brett Cannon wrote: The new doc is named securing_python.txt and can be found through the svn web interface at http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log.How do you plan to handle CPU-hogs? Stuff like execution of a giganticinteger multiplication. I don't. =) Protecting the CPU is damn hard to do in any form of portable fashion. And even getting it to work on an OS you do know the details of leads to probably an interrupt implementation and that doesn't sound fun. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
On 7/20/06, Nick Coghlan [EMAIL PROTECTED] wrote: For code objects, their construction is already commonly written ascompile(source).Right, but some people like to construct directly from bytecode. For type objects, the constructor doesn't let you do anything you can'talready do with a class statement. It doesn't need securing.I figured as much, but when I was making the list I was not sure and didn't want to stop my writing momentum to check. For rewriting import.c in Python, the PEP 302 compliant import system API in pkgutil would be a good starting point.Yep. Plan on looking at all of the various modules in the stdlib that assist with importing, package PEP (I think there is one), and PEP 302. Your doc also asks about the imp.get_suffixes() list, and wonder where to setit from Python.As far as I am aware, you can't. get_suffixes() is built from_PyImport_FileTab, which is a C array. A switch statement is used to get from the file table entries to the appropriate handler functions.Ah, OK. Quoting from the suggestions I put to the Py3k list:Use smarter data structures---Currently, the individual handlers to load a fully identified module areexposed to Python code in a way that reflects the C-style data structures used in the current implementation.Simply switching to more powerful data structures for the file type handlers(i.e. use a PyTuple for filedescr values, a PyList for _PyImport_FileTab, anda PyDict instead of a switch statement to go from filedescr values to module loading/initialisation functions) and manipulating them all as normal Pythonobjects could make the code in import.c much easier to follow.Yep. I just kind of glanced at the rest of your suggestions, Nick, since I assumed a lot of it would change (or could be changed) if import was redone in as much Python as possible. Extensible file type handling-If the file type handlers are stored in normal Python data structures as described above, it becomes feasible to make the import system extensible todifferent file types as well as to different file locations.Yep. Although I am more interested in restricting than broadening the file types. This could be handled on a per-package basis, e.g. via a __file_types__special attribute in packages. Maybe. I don't want to get into introducing new abilities to start, though.-Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
On 7/20/06, Lawrence Oluyede [EMAIL PROTECTED] wrote: That's great. I just read your draft but I have little comments to dobut before let me say that I liked the idea to borrow concepts from E.I've crossed the E's path in the beginning of this year and I found it a pot of really nice ideas (for promises and capabilities). Here aremy comments about the draft:- it's not really clear to me what the powerbox is. I think I gotthe concept of super process but maybe it's to be clarified, isn't it? It become clear in the threat model paragraphThe powerbox is the thing that gives your security domains their initial abilities. The OS gives the process its abilities, but it does not directly work with the interpreter. Since the process does, though, it is considered the powerbox and farms out abilities that it has been given by the OS. I have tried to clarify the definition at the start of the doc.- I hope no Rubystas will read the Problem of No Private Namespace section because they have private/protected keywords to enforce thisstuff :-) Writing proxies in C will slow down the dev process (altoughwill speed up the performance maybe) but in a far future someone will come up with an alternative closer to the Python levelMaybe. As I said in the doc, any changes must be Pythonic and adding private namespaces right now wouldn't be without much more thought and work. And if Ruby ends up with this security model but more thoroughly, more power to them. Their language is different in the right ways to support it.As for coding in C, thems the breaks. I plan in adding stuff to the stdlib for the common case. I might eventually think of a good, generic proxy object that could be used, but as of right now I am not worrying about that since it would be icing on the cake. - Can you write down a simple example of what you mean with changing something of the built-in objects? (in Problem of mutable sharedstate)Done. - What about the performance issues of the capabilities model overall?Should be faster than an IBAC model since certain calls will not need to check the identity of the caller every time.But I am not worrying about performance, I am worrying about correctness, so I did not try to make any performance claims. - I know what you meant to say but the paragraph about pythonicnessand the security model seems a little fuzzy to me. Which are the boundaries of the allowed changes for the security stuff?Being pythonic is a fuzzy term in itself and Guido is the only person who can make definitive claims over what is and is not Pythonic. As I have said, this doc was mostly written with python-dev in mind since they are the ones I have to convince to let this into the core and they all know the term. But I have tacked in a sentence on what the term means.- You don't say anything about networking and networked resources in the list of the standard sandboxed interpreterNope. Have not started worrying about that yet. Just trying to get the basic model laid out. - Suppose we have a .py module. Based on your security model we canimport it, right? When imported it generates a .pyc file. The secondtime we import it what happens? .pyc is ignored? import is not allowedat all? We can't rely on the name of the file.pyc because an attackerwho knows the file.py is secure and the second import is done againstfile.pyc can replace the secure file.pyc with an implementation notsecure and can do some kind of harm to the sandbox It will be ignored. But I am hoping that through rewriting the import machinery more control over generating .pyc files can be had (see Skip Montanaro's PEP on this; forget the number). This is why exact details were left out of the implementation details. I just wanted people understand the approach to everything, not the concrete details of how it will be coded up. - About Filesystem information. Does the sandboxed interpreter need to know all that information about file paths, files and so on? Can'twe reset those attributes to something arbitrary?That is the point. It is not that the sandbox needs to know it, its that it needs to be hidden from the sandbox. - About sys module: I think the best way is to have a purged fake sysmodule with only the stuff you need. pypy has the concept of faked modules too (altough for a different reason)OK. - About networking: what do you think about the E's model of really safe networking, protected remotable objects and safe RPC? Is thatmodel applicable to Python's in some way? We can't use the E's modelas a whole (ask people to generate a safe key and send it by email isunfeasible) I have not looked at it. I am also not trying to build an RPC system *and* a security model for Python. That is just too much work right now. - is the protected memory model a some kind of memory monitor system?Basically. It just keeps a size_t on the memory cap and another on memory usage, and when memory is requested it makes sure that it won't go over the cap. And when memory is freed the usage goes
Re: [Python-Dev] new security doc using object-capabilities
Brett Cannon wrote: http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log . How do you plan to handle CPU-hogs? Stuff like execution of a gigantic integer multiplication. I don't. =) Protecting the CPU is damn hard to do in any form of portable fashion. And even getting it to work on an OS you do know the details of leads to probably an interrupt implementation and that doesn't sound fun. I think the trick used by the safe_eval recipe (a separate thread which interrupts the script through thread.interrupt_main()) shows that, in most cases, it's possible to make sure that an embedded script does not take too long to execute. Do you agree that this usage case (allow me to timeout an embedded script) is something which would be a very good start in the right direction? Now, I wonder, in a restricted execution environment such as that depicted in your document, how many different ways are there to make the Python interpreter enter a long calcolation loop which does not release the GIL? I can think of bignum*bignum, bignum**bignum or similar mathematical operations, but there are really a few. If we could make those release the GIL (or poll some kind of watchdog used to abort them, pretty much like they normally poll CTRL+C), then the same trick used by the recipe could be used. -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
On 7/20/06, Giovanni Bajo [EMAIL PROTECTED] wrote: Brett Cannon wrote:http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log . How do you plan to handle CPU-hogs? Stuff like execution of a gigantic integer multiplication. I don't.=)Protecting the CPU is damn hard to do in any form of portable fashion.And even getting it to work on an OS you do know the details of leads to probably an interruptimplementation and that doesn't sound fun.I think the trick used by the safe_eval recipe (a separate thread which interrupts the script through thread.interrupt_main()) shows that, in mostcases, it's possible to make sure that an embedded script does not take toolong to execute. Do you agree that this usage case (allow me to timeout an embedded script) is something which would be a very good start in the rightdirection?Probably. I just don't feel like worrying about it right now. =) Now, I wonder, in a restricted execution environment such as that depictedin your document, how many different ways are there to make the Pythoninterpreter enter a long calcolation loop which does not release the GIL? I can think of bignum*bignum, bignum**bignum or similar mathematicaloperations, but there are really a few. If we could make those release theGIL (or poll some kind of watchdog used to abort them, pretty much like they normally poll CTRL+C), then the same trick used by the recipe could be used.Well, any work that does most of its calculation within C code and that does not touch base with the interpreter on a semi-regular basis would need to relesae the GIL. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Should be faster than an IBAC model since certain calls will not need to check the identity of the caller every time. But I am not worrying about performance, I am worrying about correctness, so I did not try to make any performance claims. Got that. Nope. Have not started worrying about that yet. Just trying to get the basic model laid out. Ok sorry to have bothered That is the point. It is not that the sandbox needs to know it, its that it needs to be hidden from the sandbox. So I think that's a simple step during the importing step. I have not looked at it. I am also not trying to build an RPC system *and* a security model for Python. That is just too much work right now. Ok sorry :-) Thanks, Lawrence. Thank you! -- Lawrence http://www.oluyede.org/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
On Wed, 19 Jul 2006, Brett Cannon wrote: I have decided to go with object-capabilities for securing interpreters. I have rewritten my design doc from scratch and deleted the old one. The new doc is named securing_python.txt and can be found through the svn web interface at http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log. This is amazing news!! I'm going off to read your document right now. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Brett Cannon wrote: After various people suggesting object-capabilities, takling with Mark S. Miller of the E programming language, and the people Mark works with at HP Labs (who have been giving talks every week during this month here at Google on object-capabilities), I have decided to go with object-capabilities for securing interpreters. I have rewritten my design doc from scratch and deleted the old one. The new doc is named securing_python.txt and can be found through the svn web interface at http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log . I have pretty much ignored any concrete API and such and gone more with a conceptual doc to make sure the API does not get in the way of the core security model. This may not be relevant or possible, in which case I apologise, but the .NET model of creating application domains is extremely useful. It allows you to assign domains and run code within those domains. This means, for example, you can create a plugin system and run the plugins in a secure domain. I realise that this was the intent of the original rexec module, and your proposed new design (which is very exciting) overcomes the difficulties in that approach. The only approach using the new system would be interprocess communication (?) with a trusted interpreter communicating with an un-trusted one. Would the communication layer need to be implemented as a C extension, or will a standard Python API be possible ? Hmmm maybe I should read your doc. :-) Michael Foord http://www.voidspace.org.uk/python/index.shtml Using object-capabilities should make the implementation much cleaner. There is much less work directly on the interpreter and more of it gets pushed up to extension modules. I also have the okay of my supervisor to use this approach in my dissertation so this will get done. Two things do fall out of all of this which will make development much more modular and easier. First, the memory cap work just becomes a special build on its own; no need to tie into the security work. So I will be cleaning up the bcannon-sandboxing branch code as it stands, and then either create a separate branch for the object-capabilities work, or create another branch for the memory cap stuff and shift the changes over there. I will most likely do the former so as to not lose the history on the checkins. I also plan to rewrite the import machinery in pure Python. This will make the code much more maintainable and make creating proxies for the import machinery much easier. I will be doing that in a directory in the sandbox initially since it needs to work from what Python has now (and possibly some new extension module code) before it can be integrated into the interpreter directly. Anyone who wants to help with that can. I already have some perliminary notes on the whole thing and I think it will be reasonably doable. Anyway, there you go. Here is to hoping I have thought this all through properly. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
Michael Foord wrote: Brett Cannon wrote: After various people suggesting object-capabilities, takling with Mark S. Miller of the E programming language, and the people Mark works with at HP Labs (who have been giving talks every week during this month here at Google on object-capabilities), I have decided to go with object-capabilities for securing interpreters. I have rewritten my design doc from scratch and deleted the old one. The new doc is named securing_python.txt and can be found through the svn web interface at http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log . I have pretty much ignored any concrete API and such and gone more with a conceptual doc to make sure the API does not get in the way of the core security model. This may not be relevant or possible, in which case I apologise, but the .NET model of creating application domains is extremely useful. It allows you to assign domains and run code within those domains. This means, for example, you can create a plugin system and run the plugins in a secure domain. I realise that this was the intent of the original rexec module, and your proposed new design (which is very exciting) overcomes the difficulties in that approach. The only approach using the new system would be interprocess communication (?) with a trusted interpreter communicating with an un-trusted one. Would the communication layer need to be implemented as a C extension, or will a standard Python API be possible ? Hmmm maybe I should read your doc. :-) Ok, started to read the doc - and realise it specifically addresses these issues. My apologies :-) Michael http://www.voidspace.org.uk/python/index.shtml Michael Foord http://www.voidspace.org.uk/python/index.shtml Using object-capabilities should make the implementation much cleaner. There is much less work directly on the interpreter and more of it gets pushed up to extension modules. I also have the okay of my supervisor to use this approach in my dissertation so this will get done. Two things do fall out of all of this which will make development much more modular and easier. First, the memory cap work just becomes a special build on its own; no need to tie into the security work. So I will be cleaning up the bcannon-sandboxing branch code as it stands, and then either create a separate branch for the object-capabilities work, or create another branch for the memory cap stuff and shift the changes over there. I will most likely do the former so as to not lose the history on the checkins. I also plan to rewrite the import machinery in pure Python. This will make the code much more maintainable and make creating proxies for the import machinery much easier. I will be doing that in a directory in the sandbox initially since it needs to work from what Python has now (and possibly some new extension module code) before it can be integrated into the interpreter directly. Anyone who wants to help with that can. I already have some perliminary notes on the whole thing and I think it will be reasonably doable. Anyway, there you go. Here is to hoping I have thought this all through properly. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
