Nelson B Bolyard wrote: > Howard Chu wrote, On 2008-08-17 22:21: >> > I think you're saying that you expect every library to have its own set of > trusted certs, as if libraries -- and not true human users -- get to decide > what certs are trusted and what are not. A human user doesn't need a > separate store of certs for every one of his libraries or applications.
You seem to think that the libraries magically decided their own security policies, when in fact the Admins who installed and configured the libraries are making those decisions. > The notion that code, and not the user, makes the security decisions about > what is trusted and what is not trusted, is the basis of many vulnerabilities. Funny you should say that, because now you're exactly agreeing with me that security policy should not be embedded in code. And yet you still defend the legitimacy of NSS_SetExportPolicy(). >> The API design is flawed and cannot be easily fixed; a full and complete >> fix would require an incompatible API change. > > We've already seen that the NSS_Shutdown issue can be solved without any > API *change*, but through the mere addition of a new function to the API. None of the solutions you've discussed are foolproof. The only way to completely fix the problem will require both an API change and a documentation change to make sure that all users (excuse me, callers) of NSS behave correctly and call Init/Shutdown correctly. If any of them does an Init without the corresponding Shutdown then you'll have dangling resources. Particularly bad if one of them obtained exclusive access to a TPM module or other dedicated hardware token. >> I suggested an approach in my previous post in this thread, but >> while it maintains a measure of compatibility it's still not fool-proof. > The thing that is being held up as the model to which we should aspire > uses a single common system-wide directory of trusted certs, e.g. > /etc/ssl/certs, or a per-LIBRARY (but nonetheless system wide) directory > of trusted certs, e.g /etc/openldap/ssl/. That's not the model we want > going forward. On a multi-user system with a dedicated sysadmin, it is appropriate for a base level of trust policy to be set system-wide. On a single-user system, the user is the admin, so whether they set policy system-wide or private to one user profile isn't really a big deal. But obviously starting system-wide keeps the use cases similar so applications don't have to deal with too many special cases. You seem to be completely ignoring the concept of machines-and-services-as-principals, which is such an obvious and powerful feature of e.g. Kerberos. You seem to be completely ignorant of the concept of proxy authorization, as implemented in various operating systems (e.g. setuid programs in Unix, impersonation in WindowsNT). It is both valid *and common* for a single process invoked by a non-privileged user to have access to privileged credentials that the users themselves could not access. It is completely safe in a system like OpenSSL because the library API never gives any single caller global access to everything the library knows about. In most cases, the admins installing a piece of software know far better what can and can't be trusted, than the users that use the software. Obviously you must agree with this to some extent, or you guys wouldn't waste so much energy debating which CAs should be included in your default bundle. But ultimately, that's a *policy* decision and the *code* has no business dictating policy. Policy is for *admins* to define, and that's what system-wide config files are for. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
