Before we add more support to secure access to trusted authentication we need to have a practical view of attack vectors
1. Secure against malicious code -------------- Here we assume that there is some malicious code/bundle running within the OSGi container and we need to secure access to trusted auth feature such that it cannot be abused. If this is the case then there is no way we can secure against it. The std means for running such non trusted code in same VM is to use Security manager. It would be similar to how Applets are executed within Browser JVM process. IMHO adding a security manager now would not be possible at all as it needs to be factored in from starting. Any other means of securing the access is bound to fail as one can resort to reflection to invoke any hidden api. 2. Prevent misuses due to programmer error ---------------- Here we assume that a person using this feature has not thought through the implications of using such a feature. Further looking at system we do not get an idea on where all this feature is being used by. Currently it requires a manual inspection of code. Here having a formal method as proposed in wiki [1] should help as it would force users of this feature to to think and enable one to determine where all it is being used 3. Prevent privilege escalation by an external user ----------------- Here we assume that an attacker is accessing the Sling system via its web interface. It needs to be ensured that an attacker is not able to escalate the account via manipulating the request parameters. So an authentication handler has to ensure that it does not populate the AuthenticationInfo in a generic way from request parameters i.e. converting parameter map to authentication info attributes. Such usage would anyway be limited and can be defended against via code review of authentication handlers which are limited in numbers So we can aim for #2 and #3 and provide support for that. Going for #1 is not possible for a system like Sling Chetan Mehrotra [1] https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem#SolvingtheAuthenticationHandlerCredentialValidationProblem-PreventingPrivilegeEscalation On Sat, Jan 11, 2014 at 7:44 AM, Alexander Klimetschek <[email protected]> wrote: > Regarding: > https://issues.apache.org/jira/browse/SLING-3179 > https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem > > I don't see how this is adding security other than reintroducing the > TrustedInfo again, just with different and more complex code. > > What I would like to see is reusing the whitelist-configurable > loginByService() approach here: an authentication handler with pre > authentication would loginByService() + impersonation – the user configured > for the service would need to be able to impersonate into all the desired > users, e.g. the admin user (but it would be an external config that admins > can control in production). > > But there is some more involved - some of this is from a f2f discussion with > Felix and Tobi: > > # Auth Handler loginByService issue > > This is difficult, since the call stack is not direct - the auth handler does > not call loginByService directly but rather passes authinfo to the sling > authenticator who does the loginByService, so the service check would see the > wrong service. > > # Pushing loginByService down to the repo > > But IMHO the service check belongs into the repository bundle, not the > jcrresourceresolver in sling. A new OakRepository replacing SlingRepository > as an extra Oak service should provide the loginByService() (and no > loginAdministrative() anymore to make a clean cut) and would live inside the > private repository space, able to access oak's inner auth mechanisms to login > as any user. > > # Big picture and goals > > This way there is a clear boundary between application/sling side and the > repository. To control repository access for all code, not just certain areas > such as JSP scripts, assuming the hacker can install bundles or trick people > into doing so or simply a broken bundle in production that exposes a security > risk and should be quickly disabled (revoking user mapping). > > With this boundary, you couldn't hack the system by adding a custom > jcrresourceresolver service allowing any logins. For this btw, any other > trusted login trick into JCR must be disabled (not sure if the Subject.doAs > is prone to that). The only thing you could do is to replace the entire > repository bundle - but there should be a way to make that fruitless. > > # loginByService can still be circumvented > > And importantly, the loginByService() check can be circumvented if you can > get the bundle context / service reference from another service that has a > loginByService user mapping. There should be a way to make that safe: > > - It might involve some OSGi extension. However, their answer would likely be > JaaS, which we want to avoid for complexity reasons. > - Another approach could be to look at the call stack for package names - but > these could be faked (private space in OSGi bundle could use same package > names) and it's not sure which call stack entry to look at. The service user > mapping would require both the package name plus bundle (+ optional service > id) to check for both at the same, although it seems you could mix both as > well (get bundle context from somewhere else + fake package name). > - Maybe something else, or maybe a little part of JaaS that just gets us this > verification in a safe way. > > # LoginModule with a loginByService check > > One could also copy the idea of loginByService for a special pre auth > LoginModule that would have a whitelist which of the sling auth handlers are > alllowed to use it to login as any user. But IMO it would be nicer to have a > single concept, because in the end (from the view of the repository) there is > no difference if that service is some background process or a auth handler > for creating a request session. And the question on making the loginByService > verification safe (point above) would apply here as well, so better to have > it in one place so it needs only be solved once. > > Cheers, > Alex
