Security in Sling

[Jukka Zitting <ju...@gmail.com>]

Hi,

I was thinking about the implications of giving a user write access to
a subtree of the repository. With that access the user could now
upload a new script and create a node that invokes that script when
rendered.

What if the script contains something like System.exit(1)? Or
something even more malicious?

Do we have mechanisms for preventing attack scenarios like that?

BR,

Jukka Zitting

Re: Security in Sling

[Bertrand Delacretaz <bd...@apache.org>]

On Wed, Apr 22, 2009 at 1:42 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Carsten Ziegeler schrieb:
>> ...scripts are
>> only picked
>> up from configured paths (libs and apps by default). So as long as the
>> user is not allowed to write in these locations, everything should be fine.
>
> Well, there is a chance here, of course: Consider the node is created as
> /content/bad with resource type "/content/malicious" and the script as
> /content/malicious/html.esp...

> Then the request to /content/bad.html would in fact call the script.

That's what I meant.

> ...Of course, restricing scripts to live in side any of the
> ResourceResolver.getSearchPath() or defining an excecution permission
> would help resolve this issue. I personally would prefer the execution
> permission approach (though it may fall short of scripting languages
> calling into the resource resolver (or the repository directly) to load
> included scripts ....)...

Restricting scripts to ResourceResolver.getSearchPath() locations
sounds much easier and less risky, at least until we have a concept of
execution permissions. There's no real reason to have scripts anywhere
else than under those search paths.

-Bertrand

Re: Security in Sling

[Felix Meschberger <fm...@gmail.com>]

Hi,

Carsten Ziegeler schrieb:
> Bertrand Delacretaz wrote:
>> Hi Jukka,
>>
>> On Wed, Apr 22, 2009 at 12:25 PM, Jukka Zitting <ju...@gmail.com> wrote:
>>> ...I was thinking about the implications of giving a user write access to
>>> a subtree of the repository. With that access the user could now
>>> upload a new script and create a node that invokes that script when
>>> rendered....
>> Requiring scripts to be stored under /libs or /apps, as a first step
>> until we have something better, could help here, as website users are
>> not supposed to be able to write to these locations.
>>
> I'm not sure if I understand the whole discussion here. But scripts are
> only picked
> up from configured paths (libs and apps by default). So as long as the
> user is not allowed to write in these locations, everything should be fine.

Well, there is a chance here, of course: Consider the node is created as
/content/bad with resource type "/content/malicious" and the script as
/content/malicious/html.esp.

Then the request to /content/bad.html would in fact call the script.

This is kind of the security downside of the full flexibility and
openness we have ....

Of course, restricing scripts to live in side any of the
ResourceResolver.getSearchPath() or defining an excecution permission
would help resolve this issue. I personally would prefer the execution
permission approach (though it may fall short of scripting languages
calling into the resource resolver (or the repository directly) to load
included scripts ....)

But it would not prevent a properly authorized user from writing and
using malicious script in /apps/sling/servlet/default/html.esp.

Regards
Felix

Re: Security in Sling

[Carsten Ziegeler <cz...@apache.org>]

Bertrand Delacretaz wrote:
> Hi Jukka,
> 
> On Wed, Apr 22, 2009 at 12:25 PM, Jukka Zitting <ju...@gmail.com> wrote:
>> ...I was thinking about the implications of giving a user write access to
>> a subtree of the repository. With that access the user could now
>> upload a new script and create a node that invokes that script when
>> rendered....
> 
> Requiring scripts to be stored under /libs or /apps, as a first step
> until we have something better, could help here, as website users are
> not supposed to be able to write to these locations.
> 
I'm not sure if I understand the whole discussion here. But scripts are
only picked
up from configured paths (libs and apps by default). So as long as the
user is not allowed to write in these locations, everything should be fine.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Security in Sling

[Bertrand Delacretaz <bd...@apache.org>]

Hi Jukka,

On Wed, Apr 22, 2009 at 12:25 PM, Jukka Zitting <ju...@gmail.com> wrote:
> ...I was thinking about the implications of giving a user write access to
> a subtree of the repository. With that access the user could now
> upload a new script and create a node that invokes that script when
> rendered....

Requiring scripts to be stored under /libs or /apps, as a first step
until we have something better, could help here, as website users are
not supposed to be able to write to these locations.

-Bertrand

Re: Security in Sling

[Ian Boston <ie...@tfd.co.uk>]

Felix,

That sounds like it would address the issue of accepting scripts from  
trusted sources but would not, make the scripts safe as per your  
original post.

On System.exit itself
I cant remember if the runtime shutdown handler can veto System.exit,  
although the damage will already be done.

enabling java security feels (to me at least) like potentially hard  
work, especially with all the OSGi classloaders in play.

Ian

On 22 Apr 2009, at 12:00, Felix Meschberger wrote:

> Hi,
>
> Ian Boston schrieb:
>> This is an interesting one for us, since all users will have write
>> access to the repository.
>> Is there an 'execute' permission in sling, or perhaps even an  
>> equivalent
>> to the no execute mount option in posix. I see some extensions to the
>> DefaultAccessControlManager looming.
>
> No, there is no such thing. Neither on the repository level nor on the
> Sling level.
>
> In fact such an exception can also not be enforced by the repository,
> since it has no notion of "execution". I think, though, the storing  
> such
> a permission would probably be possible and the scriping handlers we
> have would have to ensure the permissions, which is not currently  
> done.
>
> Regards
> Felix
>
>> Ian
>>
>> On 22 Apr 2009, at 11:25, Jukka Zitting wrote:
>>
>>> Hi,
>>>
>>> I was thinking about the implications of giving a user write  
>>> access to
>>> a subtree of the repository. With that access the user could now
>>> upload a new script and create a node that invokes that script when
>>> rendered.
>>>
>>> What if the script contains something like System.exit(1)? Or
>>> something even more malicious?
>>>
>>> Do we have mechanisms for preventing attack scenarios like that?
>>>
>>> BR,
>>>
>>> Jukka Zitting
>>
>>

Re: Security in Sling

[Felix Meschberger <fm...@gmail.com>]

Hi,

Ian Boston schrieb:
> This is an interesting one for us, since all users will have write
> access to the repository.
> Is there an 'execute' permission in sling, or perhaps even an equivalent
> to the no execute mount option in posix. I see some extensions to the
> DefaultAccessControlManager looming.

No, there is no such thing. Neither on the repository level nor on the
Sling level.

In fact such an exception can also not be enforced by the repository,
since it has no notion of "execution". I think, though, the storing such
a permission would probably be possible and the scriping handlers we
have would have to ensure the permissions, which is not currently done.

Regards
Felix

> Ian
> 
> On 22 Apr 2009, at 11:25, Jukka Zitting wrote:
> 
>> Hi,
>>
>> I was thinking about the implications of giving a user write access to
>> a subtree of the repository. With that access the user could now
>> upload a new script and create a node that invokes that script when
>> rendered.
>>
>> What if the script contains something like System.exit(1)? Or
>> something even more malicious?
>>
>> Do we have mechanisms for preventing attack scenarios like that?
>>
>> BR,
>>
>> Jukka Zitting
> 
> 

Re: Security in Sling

[Ian Boston <ie...@tfd.co.uk>]

This is an interesting one for us, since all users will have write  
access to the repository.
Is there an 'execute' permission in sling, or perhaps even an  
equivalent to the no execute mount option in posix. I see some  
extensions to the DefaultAccessControlManager looming.
Ian

On 22 Apr 2009, at 11:25, Jukka Zitting wrote:

> Hi,
>
> I was thinking about the implications of giving a user write access to
> a subtree of the repository. With that access the user could now
> upload a new script and create a node that invokes that script when
> rendered.
>
> What if the script contains something like System.exit(1)? Or
> something even more malicious?
>
> Do we have mechanisms for preventing attack scenarios like that?
>
> BR,
>
> Jukka Zitting

Security in Sling

[Rory Douglas <ro...@oracle.com>]

Bertrand Delacretaz wrote:
> 2) Prevent legitimate scripts from messing up with the system
>   
An variant of 2) just showed up in the "Accessing JCR" thread.  Looks 
like anyone that can upload a script can do the following:

<sling:defineObjects/>
<%
    SlingRepository repo = sling.getService(SlingRepository.class);
    Session superSession = repo.loginAdministrative(null);
    // and then do anything, like
    superSession.getRootNode().remove();
%>

Regards,
Rory

Re: Security in Sling

[Bertrand Delacretaz <bd...@apache.org>]

On Wed, Apr 22, 2009 at 2:44 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Wed, Apr 22, 2009 at 2:22 PM, Tobias Bocanegra <tr...@day.com> wrote:
>> System.exit() bears IMO no real risk, since it can be prevented by
>> java security.
>
> I'd like to see the relevant java security settings. With all the OSGi
> stuff, JCR bundle loading, and script compiling in place I think
> coming up with a correct security policy is a major undertaking.
>
> Do we want to go down that path, or use alternative means like the
> proposed script resolution restrictions?...

Those are different concerns:

1) Prevent users from uploading and executing arbitrary scripts

2) Prevent legitimate scripts from messing up with the system

So we probably need both approaches.
-Bertrand

Re: Security in Sling

[Felix Meschberger <fm...@gmail.com>]

Hi,

Jukka Zitting schrieb:
> Hi,
> 
> On Wed, Apr 22, 2009 at 2:22 PM, Tobias Bocanegra <tr...@day.com> wrote:
>> System.exit() bears IMO no real risk, since it can be prevented by
>> java security.
> 
> I'd like to see the relevant java security settings. With all the OSGi
> stuff, JCR bundle loading, and script compiling in place I think
> coming up with a correct security policy is a major undertaking.
> 
> Do we want to go down that path, or use alternative means like the
> proposed script resolution restrictions?

The result is different: with Java security, we do not prevent anyone
from injection scripts in the "wrong" location. With the path
alternative we do not prevent anyone from calling System.exit(0).

So, it depends on what you want ;-)

I think, the first thing might be better to be approached first. Though
I would prefer the "execution permission" approach over the path based
approach, I think the path based approach is probably easier to implement.

Regards
Felix

Re: Security in Sling

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Wed, Apr 22, 2009 at 2:22 PM, Tobias Bocanegra <tr...@day.com> wrote:
> System.exit() bears IMO no real risk, since it can be prevented by
> java security.

I'd like to see the relevant java security settings. With all the OSGi
stuff, JCR bundle loading, and script compiling in place I think
coming up with a correct security policy is a major undertaking.

Do we want to go down that path, or use alternative means like the
proposed script resolution restrictions?

BR,

Jukka Zitting

Re: Security in Sling

[Tobias Bocanegra <tr...@day.com>]

On Wed, Apr 22, 2009 at 12:41 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Jukka Zitting schrieb:
>> Hi,
>>
>> I was thinking about the implications of giving a user write access to
>> a subtree of the repository. With that access the user could now
>> upload a new script and create a node that invokes that script when
>> rendered.
>>
>> What if the script contains something like System.exit(1)? Or
>> something even more malicious?
>>
>> Do we have mechanisms for preventing attack scenarios like that?
>
> No, unless Java platform security (SecurityManager) is enabled, in which
> case the "exitVM" PlatformPersmission would be required to call
> System.exit() and likewise for other actions.

System.exit() bears IMO no real risk, since it can be prevented by
java security. scripts that heavily consume resources and/or eat CPU
in endless loops are more dangerous and much harder to detect and
prevent.

regards, toby

Re: Security in Sling

[Felix Meschberger <fm...@gmail.com>]

Hi,

Jukka Zitting schrieb:
> Hi,
> 
> I was thinking about the implications of giving a user write access to
> a subtree of the repository. With that access the user could now
> upload a new script and create a node that invokes that script when
> rendered.
> 
> What if the script contains something like System.exit(1)? Or
> something even more malicious?
> 
> Do we have mechanisms for preventing attack scenarios like that?

No, unless Java platform security (SecurityManager) is enabled, in which
case the "exitVM" PlatformPersmission would be required to call
System.exit() and likewise for other actions.

Regards
Felix

Re: Security in Sling

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Wed, Apr 22, 2009 at 12:40 PM, Torgeir Veimo <to...@pobox.com> wrote:
> The servlet container usually have default security policies defined, which
> can easily be changed. Eg for tomcat, look at conf/catalina.policy.

What would such a policy file look like, i.e. what codeBase should be
used and what permissions granted?

Also, I'm not sure how easy it would be to apply the Java security
policies to things like ESP scripts.

BR,

Jukka Zitting

Re: Security in Sling

[Felix Meschberger <fm...@gmail.com>]

Hi,

Torgeir Veimo schrieb:
> The servlet container usually have default security policies defined, which
> can easily be changed. Eg for tomcat, look at conf/catalina.policy.
> Am not sure what facilities ogsi containers provide in this area though?

OSGi containers basically also depend on standard Java security, for
example many operations in the framework and compendium services are
defined to fail with a SecurityException if some Permission is not granted.

By defualt (in Sling), Java security is turned off.

Be warned, though, Java Security is a thorny road ;-)

Regards
Felix

> 
> 2009/4/22 Jukka Zitting <ju...@gmail.com>
> 
>> Hi,
>>
>> I was thinking about the implications of giving a user write access to
>> a subtree of the repository. With that access the user could now
>> upload a new script and create a node that invokes that script when
>> rendered.
>>
>> What if the script contains something like System.exit(1)? Or
>> something even more malicious?
>>
>> Do we have mechanisms for preventing attack scenarios like that?
>>
>> BR,
>>
>> Jukka Zitting
>>
> 
> 
> 

Re: Security in Sling

[Torgeir Veimo <to...@pobox.com>]

The servlet container usually have default security policies defined, which
can easily be changed. Eg for tomcat, look at conf/catalina.policy.
Am not sure what facilities ogsi containers provide in this area though?

2009/4/22 Jukka Zitting <ju...@gmail.com>

> Hi,
>
> I was thinking about the implications of giving a user write access to
> a subtree of the repository. With that access the user could now
> upload a new script and create a node that invokes that script when
> rendered.
>
> What if the script contains something like System.exit(1)? Or
> something even more malicious?
>
> Do we have mechanisms for preventing attack scenarios like that?
>
> BR,
>
> Jukka Zitting
>



-- 
-Tor