Hi, I agree, #2 and #3 are achievable. #1 although theoretically possible is not practical. #1 not being practical underlines that the JVM is 1 security zone, and once compromised, all bets are off.
About 4 years ago, I wrote a fiendishly complex mechanism (driven by my own in JVM security paranoia) to allow AuthenticationHandlers to authenticate via a LoginModule. Was it secure to in JVM attack ? Almost certainly not. Did it make it harder than necessary to write AuthenticationHandlers and maintain them in production? Yes. I should have kept it simple and been resigned to the fact that the JVM is a single security zone. (I also went down the route of a Security Manager policy, never again). If the documentation is clear and the mechanism and implementation simple then #2 and #3 are easier to achieve. Best Regards Ian On 13 January 2014 08:05, Carsten Ziegeler <[email protected]> wrote: > I agree that #1 is a lot of work and is most probably not worth the effort, > but I don't think it's impossible and it's not that Sling by itself makes > this impossible. > > Carsten > > > 2014/1/13 Chetan Mehrotra <[email protected]> > >> 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 >> > > > > -- > Carsten Ziegeler > [email protected]
