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 compl
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 truste
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
> Before we add more support to secure access to trusted authentication
> we need to have a p
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 paranoi
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
> 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 securi
Right, good analysis! I have further important additions to #1 and #2:
#1 of course is difficult. It should be split up:
-
1a. malicious JSP/script code
Injecting a script that gets executed by Sling can be a lot easier (incorrect
ACLs on prod
1a and 1b would enable us to sandbox scripts and would be quite a good
feature to have. This would allows us to have a much better Multi
Tennant support story.
However the problem with sandboxing untrusted code in any form
requires quite a bit of an effort. Just to start with
a. Disable access to
I think using OSGi subsystems would bring at least some points of isolation
and control - it's clearly not designed for security but leveraging it is a
step closer to the goal.
Carsten
2014/1/14 Chetan Mehrotra
> 1a and 1b would enable us to sandbox scripts and would be quite a good
> feature
On 13.01.2014, at 21:15, Chetan Mehrotra wrote:
> However the problem with sandboxing untrusted code in any form
> requires quite a bit of an effort. Just to start with
>
> a. Disable access to Java reflection API
> b. Limit access to OSGi service registry
> c. Limit access to JMX. You can invok
Hi
Am 13.01.2014 um 15:26 schrieb Alexander Klimetschek :
> Right, good analysis! I have further important additions to #1 and #2:
>
> #1 of course is difficult. It should be split up:
> -
>
> 1a. malicious JSP/script code
>
> Injecting a scr
Hi
Ok, right, subsystem is one approach.
Another, quite intrusive one, might be a class loader hook: This would allow us
to filter visible classes per bundle
Yet, while this would get us the java.lang.System allowed or not ? But it not
get us "prevent System.exit". But it would get us "no refl
On Wed, Jan 15, 2014 at 1:39 AM, Felix Meschberger wrote:
> ...while this would get us the java.lang.System allowed or not ? But it not
> get us "prevent System.exit".
> But it would get us "no reflection here, sorry" ;-)...
If you're in control of the classloader that provides the
java.lang.Sys
I think, that's already solved by the SecurityManager concept - so let's
not reinvent the wheel
Carsten
2014/1/15 Bertrand Delacretaz
> On Wed, Jan 15, 2014 at 1:39 AM, Felix Meschberger
> wrote:
> > ...while this would get us the java.lang.System allowed or not ? But it
> not get us "prevent
On 15.01.2014, at 01:34, Carsten Ziegeler wrote:
> I think, that's already solved by the SecurityManager concept - so let's
> not reinvent the wheel
One solution would be to add a new interface to use that only gives access to
the allowed methods. For example, say you only want to allow
System
Eagerly waiting for a patch which implements this :)
2014/1/15 Alexander Klimetschek
> On 15.01.2014, at 01:34, Carsten Ziegeler wrote:
>
> > I think, that's already solved by the SecurityManager concept - so let's
> > not reinvent the wheel
>
> One solution would be to add a new interface to
Hello Alex
As long as reflection is still permitted I think you could get around
most (all?) of these restrictions.
I'm pretty sure this can only be solved properly on VM level
(SecurityManager).
Cheers
Lars
On 15.01.2014 23:53, Alexander Klimetschek wrote:
On 15.01.2014, at 01:34, Carsten
On 16.01.2014, at 06:49, Lars Krapf wrote:
> As long as reflection is still permitted I think you could get around most
> (all?) of these restrictions.
> I'm pretty sure this can only be solved properly on VM level
> (SecurityManager).
As I said, reflection is one of the things you have to dis
On 16.01.2014, at 05:19, Carsten Ziegeler wrote:
> Eagerly waiting for a patch which implements this :)
He he :)
This isn’t meant as something we should have soon - it is meant as a goal to
guide around the jcr login mechanism discussion.
One opinion is: ah, don’t care, once code is running i
On 16.01.2014 23:28, Alexander Klimetschek wrote:
On 16.01.2014, at 05:19, Carsten Ziegeler wrote:
Eagerly waiting for a patch which implements this :)
He he :)
This isn’t meant as something we should have soon - it is meant as a goal to
guide around the jcr login mechanism discussion.
One
On 17 January 2014 10:37, Lars Krapf wrote:
> On 16.01.2014 23:28, Alexander Klimetschek wrote:
>>
>> On 16.01.2014, at 05:19, Carsten Ziegeler wrote:
>>
>>> Eagerly waiting for a patch which implements this :)
>>
>> He he :)
>>
>> This isn’t meant as something we should have soon - it is meant a
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
Hi Lars,
On 17 January 2014 13:52, Lars Krapf wrote:
> 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 trust
On 17.01.2014, at 05:52, Lars Krapf wrote:
> 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 defaul
23 matches
Mail list logo
