Hi all, On Monday I was at an inspiring seminar about (a specific form of) language-level security. I've collected the PyPy-ification of these ideas there: http://codespeak.net/svn/pypy/dist/pypy/doc/discussion/security-ideas.txt Although the focus is different, it makes me think that we could also use similar ideas to implement a form of 'rexec' (restricted execution), with functions compiled by secure() as in the draft above, but running at a priviledge level which is lower than the default ambiant level instead of higher. A bientot, Armin
On Wednesday 24 May 2006 13:47, Armin Rigo wrote:
Hi all,
On Monday I was at an inspiring seminar about (a specific form of) language-level security. I've collected the PyPy-ification of these ideas there:
http://codespeak.net/svn/pypy/dist/pypy/doc/discussion/security-ideas.txt
Although the focus is different, it makes me think that we could also use similar ideas to implement a form of 'rexec' (restricted execution), with functions compiled by secure() as in the draft above, but running at a priviledge level which is lower than the default ambiant level instead of higher.
This is quite interesting, but I have some concerns over the scheme presented. It seems to only take into consideration who gets to see the contents of an object. However, real information security is just as often concerned with who gets to set or modify the contents of an object. This produces security classifications that can't be represented as a linear scale, leading to a much more complex infrastructure for determining what classification to give to an object that receives it from multiple parents. Jacob
Hi Jacob, On Wed, May 24, 2006 at 02:21:54PM +0200, Jacob Hall?n wrote:
This is quite interesting, but I have some concerns over the scheme presented. It seems to only take into consideration who gets to see the contents of an object. However, real information security is just as often concerned with who gets to set or modify the contents of an object. This produces security classifications that can't be represented as a linear scale, leading to a much more complex infrastructure for determining what classification to give to an object that receives it from multiple parents.
Definitely. The scheme presented doesn't propose any classification, and it allows us to experiment with variants. As presented, the levels don't have to form a linear order but only have to be arranged in a semi-lattice (i.e. where "public" is the most permissive, and for any two levels L1 and L2 we can form a higher level "L1 union L2" that represents someone with both L1 and L2 credential levels). Moreover nothing is specified about what the level means and where exactly they are enforced, so we can definitely have object attributes that require different levels to be read or modified. There are many theories available; I've heard of one where each level is actually a set of tuples, where each tuple gives an "owner" name and a set of names of persons that can read the information. Also, it's easy to come up with anything custom in this approach -- as opposed to other approaches where changing the theory requires a whole compiler to be rewritten, syntax to be redesigned, etc. A bientot, Armin.
Armin Rigo wrote:
Hi all,
On Monday I was at an inspiring seminar about (a specific form of) language-level security. I've collected the PyPy-ification of these ideas there:
http://codespeak.net/svn/pypy/dist/pypy/doc/discussion/security-ideas.txt
Although the focus is different, it makes me think that we could also use similar ideas to implement a form of 'rexec' (restricted execution), with functions compiled by secure() as in the draft above, but running at a priviledge level which is lower than the default ambiant level instead of higher.
As a general note it might be useful to talk to Jim Fulton for real-world experience concerning language-level security in Python. I'll cc him so he at least is aware of your security ideas document. In Zope 2, there is a precompiler for untrusted Python code, offering, as far as I understand, true language-level security. In Zope 3 this approach has been dropped as hard to maintain and replaced with object level security (attribute access is controlled with a permission system). Regards, Martijn
On Wed, May 24, 2006 at 01:47:28PM +0200, Armin Rigo wrote:
On Monday I was at an inspiring seminar about (a specific form of) language-level security. I've collected the PyPy-ification of these ideas there:
http://codespeak.net/svn/pypy/dist/pypy/doc/discussion/security-ideas.txt
Let me add a reference, just in case it could be useful to future readers of the archives: http://en.wikipedia.org/wiki/E_programming_language -- Nicolas Chauvat logilab.fr - services en informatique avancée et gestion de connaissances
Hi Armin, On Wed, May 24, 2006 at 13:47 +0200, Armin Rigo wrote:
On Monday I was at an inspiring seminar about (a specific form of) language-level security. I've collected the PyPy-ification of these ideas there:
http://codespeak.net/svn/pypy/dist/pypy/doc/discussion/security-ideas.txt
IIUC, in this discussion you argue against an "Proxy-Object space" solution because a code block may depend on a condition involving secret values. In your alternative "annotator" suggestion, you give the following example: def enter_bid(n): if n > highest_bid.value: highest_bid.value = n enter_bid = secure(enter_bid) Here the annotator analysis is supposed to prevent a leak of information from the secret value. But if the if-branch additionally contains: num_bids += 1 don't you run into a branching/code-dependent-on-secret-condition problem again? Would the annotator prevent the manipulation of the global 'num_bids'? Would it need to be a public value? Moreover, i have practical concerns: your proposed scheme requires RPython annotator analysis which implies to have the PyPy tool chain available and accessible at programming time. Not impossible but also not a use case that we went for so far. Also it is not clear to which target "secure" would compile functions to, C or bytecode or ...? best, holger
Hi Holger, On Thu, Jul 13, 2006 at 08:02:29AM +0200, holger krekel wrote:
def enter_bid(n): if n > highest_bid.value: highest_bid.value = n enter_bid = secure(enter_bid)
Here the annotator analysis is supposed to prevent a leak of information from the secret value. But if the if-branch additionally contains:
num_bids += 1
don't you run into a branching/code-dependent-on-secret-condition problem again? Would the annotator prevent the manipulation of the global 'num_bids'? Would it need to be a public value?
You can't modify global values in RPython anyway. But more generally, yes, the annotator would follow all mutations and propagate security levels.
Moreover, i have practical concerns: your proposed scheme requires RPython annotator analysis which implies to have the PyPy tool chain available and accessible at programming time. Not impossible but also not a use case that we went for so far.
Well, we haven't considered much at all. This is just one approach, which we didn't think of earlier, but there are of course others.
Also it is not clear to which target "secure" would compile functions to, C or bytecode or ...?
I don't know. That's not too important for the security aspect; anything would work, maybe even to the point of not actually compiling at all but just using the annotator for the security proof (although I'd regard this as less secure somehow, given the subtle differences between RPython and full Python). A bientot, Armin
Hi Armin, On Mon, Jul 17, 2006 at 20:02 +0200, Armin Rigo wrote:
On Thu, Jul 13, 2006 at 08:02:29AM +0200, holger krekel wrote:
def enter_bid(n): if n > highest_bid.value: highest_bid.value = n enter_bid = secure(enter_bid)
Here the annotator analysis is supposed to prevent a leak of information from the secret value. But if the if-branch additionally contains:
num_bids += 1
don't you run into a branching/code-dependent-on-secret-condition problem again? Would the annotator prevent the manipulation of the global 'num_bids'? Would it need to be a public value?
You can't modify global values in RPython anyway. But more generally, yes, the annotator would follow all mutations and propagate security levels.
Hum, sorry for having asked too many questions at once. Obviously, i could have said "whatever.num_bids +=1". Anyway, it seems that we cannot avoid the "dependent code block" issue but you consider the annotator more suited than an object space to deal with it, right? Also, from your answers i gather that your focus is more on getting something at-or-beyond-state-of-the-art first rather than to provide something directly practical. Probably makes sense. best, holger
participants (6)
-
Armin Rigo -
holger krekel -
hpk＠trillke.net
-
Jacob Hallén -
Martijn Faassen -
Nicolas Chauvat