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).
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
.
