On Sun, 30 Mar 2003, Paul Prescod wrote:
I'm not clear (because I've been following the thread with half my brain, over quite a few days) whether you are making or have made some specific proposal. I guess you are proposing a restricted mode that would make this example actually secure as opposed to almost secure. Are you also proposing any changes to the syntax?
Not yet. Although it's certainly tempting to propose syntax changes, it makes more sense to really understand what we want first. We can't know that until we've actually tried programming in the capability style in Python. That's why i want to explore the possibilities and try these exercises -- it will help us discover the shortest path from here to there.
Also, is restricted mode an interpreter mode or is it scoped by module?
Whether restricted mode is activated depends on the __builtins__ of the current namespace. So the short answer is "by module".
Yes, but why workaround rather than fix? Is there a deep reason Python objects can't write to intermediate namespaces?
No. There's just no syntax for it yet. But let's figure out what we can get away with first.
It would be cool if you could suggest little "security challenges" to work through. Given specific scenarios requiring things like mutability or friend classes, i think trying to implement them in this style could be very instructive.
Unfortunately, most of the examples I can come up with seem to be hacks, workarounds and optimizations. It isn't surprising that sometimes you lose some efficiency or simplicity when working in a secure system.
Hmm, i'm not sure you understood what i meant. The code example i posted is a solution to the design challenge: "provide read-only access to a directory and its subdirectories, but no access to the rest of the filesystem". I'm looking for other security design challenges to tackle in Python. Once enough of them have been tried, we'll have a better understanding of what Python would need to do to make secure programming easier.