Hi, On 05/28/21 06:09, Ron Pressler wrote: > Before getting into alternatives and the vision for what would be possible > post-SecurityManager, it would help to explain what the use-case and > requirements are. > > When we talk about untrusted code we usually mean code that you believe > might be malicious and intentionally try to break through any restrictions > you place on it and attack you by any means, including denial-of-service, > while trusted code is assumed to not be malicious. > > From what you’ve written I gather that you only intend to run trusted > “plugins", but wish to restrict their operations so that they don’t break > some application invariants and accidentally interfere with its operation.
It seems to me that PostgreSQL's trusted/untrusted distinction (which is a distinction baked into the core PostgreSQL project and therefore common to all of the different programming-language supporting extensions like the Java one that I maintain) is aimed at a sort of intermediate threat model. The key consequence of whether a PL is declared to PostgreSQL with or without the TRUSTED keyword is which database user identities will be able to CREATE FUNCTION in that language. If it is not declared trusted, only the database superuser can create functions using it. If it is declared trusted, the database superuser will be able to GRANT USAGE ON LANGUAGE ... to other database user identities, and they will then be able to CREATE FUNCTION in that language. Here it matters that "database user identities" are usually a pretty small set. Acme Corp's customers won't all have database logins; they probably interact with it through a web app that uses its own credentials for a db connection. The few people with database logins are probably all on Acme payroll, and relatively trusted. If Acme's DBA has said GRANT USAGE ON LANGUAGE java TO bob; then probably Bob is not expected to go installing malicious Java functions. Bob is probably a developer and expected to apply reasonable skill at writing safe ones. The functions, once installed, may be /executed/ by a larger number of database IDs, including possibly via the web apps, so might be executed with /inputs/ crafted as maliciously as external attackers can dream up. So I think it might be said (perhaps the core PostgreSQL devs would hold otherwise) that it's /essential/ for the mechanism to be adequate to protect against oversights and mistakes in Bob's code or the libraries he relies on, including mistakes that might be exposed to malicious external inputs. It's /desirable/ for the mechanism to be robust against a malicious Bob himself, but I'm not sure how many, if any, of PostgreSQL's available PLs could be rigorously proven to be so. > If that is the case, would a “shallow” sandbox, that restricts which APIs > are available to the plugin (e.g. only expose special APIs to interact > with files that go through filtering mechanisms) rather than restrict > low-level operations where they “bottom out” before being passed to the OS, > suffice It's possible a new design in a green field would be able to take that approach. One thing I should have mentioned, and forgot to, is that there's an actual ISO standard, ISO 9075-13, SQL Routines and Types Using the Java™ Programming Language, constraining how this stuff has to work. That's kind of unique among the extension languages; the maintainers of PL/Python or PL/Ruby, lucky devils, can follow their own visions of what SQL functions in those languages should look like. 9075-13 certainly doesn't say anything about a limited or special API that the function will be required to use. That would be a disruptive change to arbitrary amounts of standard-compliant code. (Naturally, as the standard was developed back when nobody thought the J2SE security architecture would be going away, it would have been assumed that the regular API could be used and permissions would control it.) That said, it might be about time for working group 3 to convene for another look at 9075-13; it hasn't been updated in a while, and I don't think it groks JPMS yet either; user code is treated as classpath code. The PostgreSQL core team has a rep on that working group, so maybe it will be possible to plant that idea. I don't think these things move very quickly. Still, I think a change as drastic as "you must now change the API you use to be some different limited version" could be a tough sell. > While a complex, stack-dependent, deep sandbox *could* be used for plugins, > permissions that don’t specify what is forbidden but what is allowed > effectively also severely limit the use of third-party libraries, that > for example, might want to do benign operations with their own files, Well, the chief cause of that problem has historically been that the third-party library devs have been sloppy about getting doPrivileged where it belongs ... or, to put it more charitably, they haven't been given any way less cumbersome than doPrivileged to indicate which of their file operations, for example, are taint-free and which aren't. This might be the time to think about what a less-cumbersome way to do /that/ might look like. Perhaps it might still suffer from less-than-perfect uptake among library devs, and would still leave app devs having to make some nuisance permission adjustments (though perhaps with the de-facto standard policy and permission design going away, there's also an opportunity to set something up that could deny as well as grant). I still think it would be highly desirable for the JDK itself to adopt some such mechanism, if it can be made sufficiently non-cumbersome, and perhaps limited just to file operations, just as a way to usably preserve all the vital information that now exists in the code base in the form of doPrivileged blocks and will inevitably disappear or begin to rot following this JEP. That's the information that will make it possible to really say "we're not providing an enforcement mechanism anymore but one can be practically developed outside the JDK if it is needed." Having to make policy adjustments around third-party libraries might always be an occasional nuisance, but I think it would be a huge destruction of existing critical information if suddenly that nuisance became needed for all of the incidental taint-free file operations inside the JDK itself, when they are, at the moment, properly marked. Regards, -Chap
