Yepp, let's target for #2 and #3 - all I tried to say is that #1 is not a problem which only Sling has :)
Carsten 2014/1/13 Ian Boston <[email protected]> > 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] > -- Carsten Ziegeler [email protected]
