创建基于功能的受限执行系统 [英] Creating a capabilities-based restricted execution system
问题描述
我一直在和Zope'的RestrictedPython一起玩，而且我认为我是在做出必要的修改来创建一个
基于能力的受限执行系统。我们的想法是剥离
RestrictedPython的任何部分，这不是执行功能所必需的，而是只使用功能来完成所有安全性。
能力背后的基本思想是你不会给任何你不相信的代码你不想要它的代码代码
访问权限。你使用代理（E称它们为facets）。
为了能够允许不受信任的代码创建代理对象，我需要
能够在
私有属性中存储对代理对象的引用。
要创建私有属性，我正在使用名称修改 ，"其中名称
在类定义中以X_开头变为
_< uuid> _< name> ;,其中UUID对于该类是相同的。 UUIDs
不需要是安全的，因为实际上不可能以RestrictedPython中的下划线开头创建你自己名字的
;他们只需要
在所有编译器调用中都是唯一的。
使用这个名称修改的好处是它只在
编译时间并不会影响运行时性能。一个有趣的方面
效果是在类上定义的代码可以访问该类的所有后代的私有属性，但只有那些由其他人定义的属性
该类的
代码，所以这不是安全问题。
我以为我需要只读属性才能避免
不受信任的代码'能够破坏代理上的撤销方法
对象，但我想只是保留对
撤销的引用原始代码中的方法可能就足够了。
有人认为我在这里完全走错方向吗？我是否b $ b缺少任何明显的东西？
I''ve been playing around with Zope''s RestrictedPython, and I think I''m
on the way to making the modifications necessary to create a
capabilities-based restricted execution system. The idea is to strip out
any part of RestrictedPython that''s not necessary for doing capabilities
and do all security using just capabilities.
The basic idea behind capabilities is that you don''t give any piece of
code you don''t trust a reference to something you don''t want it to have
access to. You use proxies instead (E calls them "facets").
In order to be able to allow untrusted code to create proxy objects, I
needed to be able to store a reference to the proxied object in a
private attribute.
To create private attributes, I''m using "name mangling," where names
beginning with X_ within a class definition get changed to
_<uuid>_<name>, where the UUID is the same for that class. The UUIDs
don''t need to be secure because it''s not actually possible to create
your own name starting with an underscore in RestrictedPython; they just
need to be unique across all compiler invocations.
The nice thing about using this name mangling is that it''s only done at
compile time and doesn''t affect runtime performance. An interesting side
effect is that code defined on a class can access private attributes on
all descendants of that class, but only ones that are defined by other
code on that class, so this isn''t a security issue.
I was thinking I needed read-only attributes to be able to avoid
untrusted code''s being able to sabotage the revoke method on a proxy
object, but I''m thinking that just keeping around a reference to the
revoke method in the original code may be enough.
Does anyone think I''m going in completely the wrong direction here? Am I
missing anything obvious?
推荐答案
" Sean R. Lynch" < SE *** @ chaosring.org>写道：
"Sean R. Lynch" <se***@chaosring.org> writes:
有人认为我在这里完全走错方向吗？我错过了什么明显的东西？
Does anyone think I''m going in completely the wrong direction here? Am
I missing anything obvious?
好吧，我有一个愚蠢的问题。你有没有研究过rexec / Bastion的安全问题，并且确信自己没有碰到你的新计划？
你可能会看看PyPy架构文档，如果你还没有。
为受限制的对象创建一个单独的对象空间可能适合PyPy的
设计非常自然。
Well, I have a dumb question. Have you studied the security failures
of rexec/Bastion and convinced yourself that they don''t happen to your
new scheme?
You might look at the PyPy architecture doc if you haven''t yet.
Making a separate object space for restricted objects may fit PyPy''s
design quite naturally.
Paul Rubin写道：
Paul Rubin wrote:
好吧，我有一个愚蠢的问题。你有没有研究过rexec / Bastion的安全问题，并确信自己没有碰到你的新计划？
如果您知道rexec已知缺陷的位置
，请告知我们。到目前为止，我只看过几个例子
和很多人说它不安全所以让我们禁用它。
我目前的方法是要非常小心地添加任何特权
超出RestrictedPython所允许的范围。
你可以查看PyPy架构文档，如果你没有'还没有。
为受限制的对象创建一个单独的对象空间可能非常适合PyPy的设计。
Well, I have a dumb question. Have you studied the security failures
of rexec/Bastion and convinced yourself that they don''t happen to your
new scheme?
If you know of a location where the known shortcomings of rexec are
documented, please let me know. So far I''ve only seen a couple examples
and a lot of people saying "it''s not secure so let''s disable it."
My current methodology is to be very careful about adding any privileges
beyond what RestrictedPython allows.
You might look at the PyPy architecture doc if you haven''t yet.
Making a separate object space for restricted objects may fit PyPy''s
design quite naturally.
我看过了PyPy。这很有意思，但RestrictedPython已经在Zope中编写并使用了
。
我想我已经找到了一种使用方法我的名字修改方案要使
属性只有*可写*由在一个类上定义的代码，
对象下降：通过一个名称错误的方法写入，并且有
RestrictedPython为每个
尝试的属性赋值输出self._mangled_setattr（attr，val）。这基本上使得从其他类中可以写入的属性基本上不可能获得b / b
，但我认为它可能是功能的先决条件。大多数其他语言
要求通过方法设置属性，对吧？
I have looked at PyPy. It''s very interesting, but RestrictedPython is
already written and in use in Zope.
I think I''ve figured out a way to use my name mangling scheme to make
attributes only *writable* by code defined on a class from which an
object descends: do writes through a name-mangled method, and have
RestrictedPython output self._mangled_setattr(attr, val) for each
attempted attribute assignment. This will basically make it impossible
to have attributes that are writable from other classes, but I think
it''s probably a prerequisite for capabilities. Most other languages
require attributes to be set via methods anyway, right?
Sean R. Lynch写道：
Sean R. Lynch wrote:
如果您知道有关rexec已知缺点的位置，请告知我们。到目前为止，我只看过几个例子，很多人说它不安全所以让我们禁用它。
If you know of a location where the known shortcomings of rexec are
documented, please let me know. So far I''ve only seen a couple examples
and a lot of people saying "it''s not secure so let''s disable it."
最大的问题是新式的类都可以通过类型（）内置的
获得，并且可以调用来创建新的实例。
例如，如果你设法打开一个文件对象f，那么
type（f）（&etc / passwd"）。read（）
允许您访问不同的文件，绕过所有可能设计的机器，以防止这种情况发生。
当然，对于文件对象的特定情况，还有额外的
机制阻止这种情况发生，但在一般情况下，
在该区域可能存在更多问题。例如，
object .__子类__（）可以让你访问很多东西。
问候，
Martin
The biggest problem is that new-style classes are both available through
the type() builtin, and callable to create new instances.
For example, if you have managed to open a file object f, then
type(f)("/etc/passwd").read()
lets you access a different file, bypassing all machinery that may
have been designed to prevent that from happening.
Of course, for the specific case of file objects, there is additional
machinery preventing that from happening, but in the general case,
there might be more problems in that area. For example,
object.__subclasses__() gives you access to quite a lot of stuff.
Regards,
Martin
这篇关于创建基于功能的受限执行系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
