Re: [Python-Dev] what can we do to hide the 'file' type?
Hi Brett, On Wed, Jul 05, 2006 at 05:01:48PM -0700, Brett Cannon wrote: And if Armin and/or Samuele sign off that what we find is most likely (with most likely equalling 99% chance) all there is, then bonus points and I will *really* be convinced. =) I don't think I can sign off that. Really hiding Python objects is quite hard IMHO. 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] what can we do to hide the 'file' type?
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. 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()). 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). -- Michael Chermside ___ 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] what can we do to hide the 'file' type?
On 7/6/06, Michael Chermside [EMAIL PROTECTED] wrote: 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 hidingfile, we cripple it. Completely. Modify the file type so that whenexecuting on a sandboxed interpreter, all of the dangerous methodsand 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 andcan 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-usedtype, and very hard to hide, and instead we rely on our ability towrite 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 ___ 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] what can we do to hide the 'file' type?
On 7/6/06, Armin Rigo [EMAIL PROTECTED] wrote: Hi Brett,On Wed, Jul 05, 2006 at 05:01:48PM -0700, Brett Cannon wrote: And if Armin and/or Samuele sign off that what we find is most likely (with most likely equalling 99% chance) all there is, then bonus points and I will *really* be convinced.=)I don't think I can sign off that.Really hiding Python objects isquite hard IMHO.=) That's fine. I didn't expect you to, especially without people either finding more instances of ways to get to 'file' or stating that they really tried and couldn't find any way to get to it. -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] what can we do to hide the 'file' type?
On 7/6/06, Michael Chermside [EMAIL PROTECTED] wrote: Me: 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.Brett: This is basically what I proposed in the first place! runs around in circles, pulling at his hair like a crazy manNot quite. Your original proposal had the file type throwing exceptions when the user did something they weren't allowed to(access a file not on the list, etc). This version proposes thatit *always* fails, and creates a separate beast (theSecureFileWrapper) for applying the restrictions. Why? Because if the C code in file enforces the rules, then all possiblerules need to be written in advance, and you have to hold longarguments about whether to allow subdirectories, restrict filesizes, etc. Whereas SecureFileWrapper could delegate its restrictions to Python functions provided by the USER and thenUSERS could design whatever level of restriction they wanted.Ah, OK, that makes more sense. I was not thinking about allowing for specifying a factory function to return the specific object to use when using open(). That could be rather handy and cool. I will definitely see if I can work it into the API in a reasonable way. -BrettImagine we want some code to be able to open files only if they contain the letter 'w': # get my own wrapper from __builtins__ myFileWrapper = file # define a function to constrain my callers def filenameContainsLetterW(path, mode): filename = os.path.basename(path) if 'w' not in filename and 'W' not in filename: raise PyXXX_SecurityException # create more restrictive wrapper class MustHaveW_FileWrapper: __metaclass__ = SecureFileWrapperMeta wrapped_file = init_condition = filenameContainsLetterW # register the wrapper so it applies to any code # in this stack frame or lower. The restriction is # automatically lifted when the current stack # frame exits. PyXXX_RegisterFileWrapper( MustHaveW_FileWrapper ) # Invoke less-trusted code with restrictions in place less_trusted_code()If the code fragment shown above ALREADY received a wrapped form of file which was restricted to read-onlyaccess, then less_trusted_code() would be restrictedto read-only access to files containing 'w'.Okay, the syntax needs work, but the idea is that I can defin restrictions *in python* and apply them to othercode. Using the stack to enforce wrappers is somethingPython code cannot get around (although it does preventpassing more-powerful callbacks to later stackframes). It all depends on whether we think that a simple setof restrictions implementable in C (such as 4 lists:read-only files, read-write files, read-only dirs,write-only dirs) will be sufficient, or if it is valuable to allow end users to fine-tune therestrictions.-- Michael Chermside ___ 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
[Python-Dev] what can we do to hide the 'file' type?
To make sure I don't unfairly block out capabilities as a complete security model instead of just crippling 'file's constructor (I do like capabilities and think it is a good model, really!), let's discuss how one can get to the 'file' type without importing any extension modules (that can be protected at the import level so I am ignoring the 'gc' module trick and such). First, it's in __builtin__. That reference can just be left out of the dict at the PyInterpreterState stuct's dict for built-ins. But we all know it isn't that simple.Second, there is __subclasses__(). That method could just not be allowed to be in the 'type' class at the Python level (hiding it, crippling it, whatever), but would that break much code? I don't know, but I doubt it. Third, for any wrappers returned by open(), it cannot be a subclass because chaining __class__ attribute, mro() (or any of the other methods provided on 'object' or 'type'), or type() will get you to the original 'file' type. The actual 'file' reference will need to be stored at the C struct level for the wrapper and not accessed except by the wrapper directly which would be implemented in C. Can anyone think of any other way to gain access to 'file' without importing a module? At that point one would need to be *very* careful about what an extension module exported to the world, but I can live with that (as that is already part of the plan). Please seriously try to think of ways to get to 'file' everybody. If we really cannot come up with anything beyond these three ways, then I am totally willing to go with a much more complete capabilities system for security in Python and really minimize any crippling. I just need to be convinced that we won't be plugging holes in how to hide 'file' rather than plugging holes from crippling 'file' (which, at this point, I am not convinced of). And if Armin and/or Samuele sign off that what we find is most likely (with most likely equalling 99% chance) all there is, then bonus points and I will *really* be convinced. =) ___ 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] what can we do to hide the 'file' type?
Brett Cannon wrote: Can anyone think of any other way to gain access to 'file' without importing a module? In principle, it might be possible to find file in the func_defaults or func_globals of some function, which might be defined as orig_file = file def file(...): ... I couldn't find any such function in the standard library, though. Regards, Martin ___ 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
