(original) (raw)
On 7/6/06, Michael Chermside <mcherm@mcherm.com> wrote:
This is basically what I proposed in the first place! <runs around in circles, pulling at his hair like a crazy man>
Yeah, it would be through open() if we returned wrappers instead of performing the checks directly in file itself.
That is another possibility. Should simplify the code as well by having less checks and just have pure PySandbox\_IsTrusted() checks in 'file' itself in unsafe places instead of a ton checks that the file being accessed is allowed.
-Brett
Armin Rigo writes:
> I don't think I can "sign off" [on hiding the file type]. Really hiding
> Python objects is quite hard IMHO.
I agree. But we don't have to give up yet. How about instead of hiding
file, we cripple it. Completely. Modify the file type so that when
executing on a sandboxed interpreter, all of the dangerous methods
and attributes of file throw exceptions.
This is basically what I proposed in the first place! <runs around in circles, pulling at his hair like a crazy man>
Then we create a separate thing (in C) called a "SecureFileWrapper".
It has methods that are passed a reference to a file object and
can invoke the methods without error. We provide a means for obtaining
a SecureFileWrapper bound to a given file (perhaps open()).
Yeah, it would be through open() if we returned wrappers instead of performing the checks directly in file itself.
Essentially, we give up on hiding file, which is a frequently-used
type, and very hard to hide, and instead we rely on our ability to
write a reliably secure "SecureFileWrapper" class (in C).
That is another possibility. Should simplify the code as well by having less checks and just have pure PySandbox\_IsTrusted() checks in 'file' itself in unsafe places instead of a ton checks that the file being accessed is allowed.
-Brett