Hi Lars, On 17 January 2014 13:52, Lars Krapf <[email protected]> wrote: > Hello Ian > > On 17.01.2014 12:19, Ian Boston wrote: >> >> [...] > > >> What was the problem with TrustedCredentials ? I might be thinking of the >> wrong thing and you might be talking about something different. > > > When I talk about trusted credentials, I refer only to the previous > implementation that relied > on an attribute (configured once for the login-module(s) and once for the > authentication handler). > which was stored in plain-text, and had a default value that you still can > find in many production-instances out there. > Once that config leaks, it could easily lead to administrative compromise of > the repo in many cases, > so this clearly was something that needed improvement. > > The method we will use now makes use of the pre-authenticated handling of > the LoginContextProvider (previously in JR RepositoryImpl), > which indeed relies solely on the JVM for security. What you describe below > is much more sophisticated, > and would definitely improve the security of the authhandler->loginmodule > trust-binding a great deal. > > However I do not fully share Alex's optimism that the VM can be sufficiently > secured to restrict access > to reflection, runtime or FS without a major rewrite of the whole Sling > layer - so whoever can deploy > code to the instance will find a way to escalate privileges in one way or > another - > This is reflected in the current threat-model and thus pre-authentication > does not violate the specified trust > boundaries. Further this means that loginService() is primarily a measure > against malicious users, not developers. > > I see your method as a great security in depth measure, and a step in the > right direction, > but without Java security, there are limits to what we can or should do > (IMHO).
I agree. I share your concerns about protecting the JVM. I shared the approach because I've used it before in Sling when I needed to address this issue. Unfortunately it meant also forking the JR SecurityManager and the JR UserManager to make it work without JAAS. In hindsight, the protection was overkill, we didn't need to protect the JVM internally. We thought 3rd party code was going to be allowed into the JVM, non engineers looked to engineers to guarantee it was safe, but no engineer was prepared to do that. Code review was considered, but again no one felt safe. In the end the apps went 100% client side. The UI team felt able to review. Best Regards Ian > > Best greetings > Lars > >> >> I am thinking of a class that implements Credentials that is trusted >> by whatever logs into the repository. That class is available via >> factory service that looks at who is calling it and does some basic >> checking (eg get the byte code of the caller and sha1 it, or anything >> else that verifies trust between the caller and the service, but >> doesn't rely on the JVM for that verification). That class seals its >> contents against tampering on construction and does not require a >> password. >> >> Anything that needs to get trusted credentials is configured to be >> allowed access, in a place that the JVM cant tamper with. (ie OS file >> containing sha1s of the class defs not writable by the owner of the >> JVM process) >> >> I am assuming (from memory) that Credentials can be added to >> AuthenticationInfo and used by whatever repository (JCR2/Oak/etc) >> chooses to trust them during the login operation. >> >> I am not thinking about JAAS... because that hurts my brain, ;) >> >> >> Ian >> >>> (null-login) is hopefully soon. >>> >>> >>>> Otherwise I don’t even know why we removed the TrustedInfo in the first >>>> place. >>> >>> >>> Because it is inherently insecure to have a preconfigured plain-text >>> admin >>> password laying around, that needs to be changed in two places just to >>> establish trust. >>> >>> Cheers >>> Lars >>> >> . >> >
