Re: Security in Sling
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 jukka.zitt...@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
Re: Security in Sling
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
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
Re: Security in Sling
Hi, On Wed, Apr 22, 2009 at 12:40 PM, Torgeir Veimo torg...@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
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 jukka.zitt...@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
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
Hi Jukka, On Wed, Apr 22, 2009 at 12:25 PM, Jukka Zitting jukka.zitt...@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
Bertrand Delacretaz wrote: Hi Jukka, On Wed, Apr 22, 2009 at 12:25 PM, Jukka Zitting jukka.zitt...@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 cziege...@apache.org
Re: Security in Sling
Hi, Carsten Ziegeler schrieb: Bertrand Delacretaz wrote: Hi Jukka, On Wed, Apr 22, 2009 at 12:25 PM, Jukka Zitting jukka.zitt...@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
On Wed, Apr 22, 2009 at 1:42 PM, Felix Meschberger fmesc...@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, 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
On Wed, Apr 22, 2009 at 12:41 PM, Felix Meschberger fmesc...@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
Hi, On Wed, Apr 22, 2009 at 2:22 PM, Tobias Bocanegra tri...@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
Hi, Jukka Zitting schrieb: Hi, On Wed, Apr 22, 2009 at 2:22 PM, Tobias Bocanegra tri...@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
On Wed, Apr 22, 2009 at 2:44 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Wed, Apr 22, 2009 at 2:22 PM, Tobias Bocanegra tri...@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
