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]
