Noah Kantrowitz wrote:
On Thursday 26 January 2006 04:17 pm, Jesse Kempf wrote:The "Mandatory Access Control" that I mentioned in my previous email trips over the trusted-system definition of MAC and gloms some things together inappropriately. We can divide this into two parts: Part 1: Non-Circumventable Access Control: Requirement: It must not be possible for a Component (read: malicious (or clueless) plugin to circumvent the security system. Consequence 1: Access control must be implemented as close to the data access layer as possible. Consequence 2: It must not be possible to acquire a reference to the SecuritySystem component, then redefine its methods, thus bypassing the system entirely.Though I have not played with this in any depth, I think that it may become almost impossible to do these kinds of things in Python. The Python VM offers little to no support for security when it comes to code loaded into the same runtime environment. I think trying to do this in the light of requests from the outside world is a good idea, but protecting the inner workings of a class may be a bit of overkill. The responsibility for this, in my mind, rests with the admin of the site. If they doubt the competency or integrity of the author/plugin, they should audit the code themselves. I don't think it is the job of Trac to protect one plugin from another.
I was about to write a reply along the same lines. Even if you'd implement a clever mechanism to control access to the SecurityComponent, an untrusted plugin could always by-pass it, by using a native extension, for example. So plugins have to be trusted (or audited) anyway. Then, don't forget that the Trac admin (not a Security admin!) has always full access to the DB itself, outside of the scope of the data access layer we'd have in python. So he also has to be trusted and there's no complete auditing possible, unless the underlying components (db, language, even OS?) are themselves secure. The bottom line is that I don't think it would make any good to try to protect against _code_. Trying to protect the integrity of the DB from malicious _users_ would be good enough :) As for the rest of your proposal (which I'll comment later), I find it very interesting. -- Christian _______________________________________________ Trac-dev mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac-dev
