Sling and Security (was: Re: ResourceAccessGate (SLING-2698))

[Angela Schreiber <an...@adobe.com>]

hi carsten

> Finally, although this feature is optional and has no impact if not
> used, there are valid concerns that this might be easily abused. But
> we can't prevent anyone from abusing stuff and we already have various
> places where people do funny things.

just to make it very clear: it's not only that people make funny
things. it's infinitely easy to create critical security issues
with sling without noticing and i hope you are aware of this.

i don't want to spread FUD here but IMHO it's time that the sling
community is taking security concerns serious and thrives for a
project that is secure by default.

statements like "Features can be abused - no matter what we do"
will likely create the impression that you don't really care.

kind regards
angela

Re: Sling and Security

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

On Thu, Mar 7, 2013 at 12:09 PM, Angela Schreiber <an...@adobe.com> wrote:
> ...b) the script execution: that's obviously related to the former with
> one additional twist. everyone that can create a script may not only
> become admin in sling but also gets file system access....

That's "anyone who can write a script inside /libs or /apps", right?

In which case it's relatively easy to prevent with strict ACLs on
those paths , and if not we should create specific issues to plug any
holes.

-Bertrand

Re: Sling and Security

[Angela Schreiber <an...@adobe.com>]

hi carsten and ian

thanks for the clarification.
feel asserted that we will report any vulnerabilities to the
sling-security list as we detect them.

what i would love to discuss on the list in general are
ways or possibilities on how we could prevent the strength
and flexibility of sling to turn into a setup that becomes
insecure due to the complexity that comes with what we all
agree is a great thing with a lot of benefit.

for example:

a) instead of training people, imposing strict rules or running after
SlingRepository#loginAdministrative calls (hi sisyphus, welcome back
on earth), wouldn't it be preferable to target this at the root i.e. at 
the sling layer? having a way to limit the admin-login to "real" admin
tasks (real in quotes because afaik that separation doesn't exist)?

b) the script execution: that's obviously related to the former with
one additional twist. everyone that can create a script may not only
become admin in sling but also gets file system access.

i don't have a solution at hand for neither of them not to mention a
simple one-line-fix... they are not bugs s.str. (works and works as
designed) but still it would IMO be very cool if there was a way to
get a better and reliable handling for them... these kind of things
would IMO make sling secure by design and by default.

regards
angela










On 3/7/13 7:45 AM, Carsten Ziegeler wrote:
> Hi Angela,
>
> you're definitely missinterpreting my sentences - I care, but even
> more important the Sling community cares a lot about security.
>
> Sure, we can always do better - but it's important that we work
> together as a community on all aspects of Sling - security is of
> course an important part here, but we should also think about the
> goals of Sling and most importantly our users - of course not
> sacrificing security (This is not targeted directly at you, but just a
> general statement).
>
> And it's good that you, Lars and others share your experience and
> concers, that's really appreciated. Maybe I got a little bit overboard
> with my comments, as I'm really disappointed how this discussion went.
>
> And as Ian said, if you are aware of any other security problems which
> we didn't noticed, please share your insight (either publically or
> private)
>
> Thanks
> Carsten

Re: Sling and Security (was: Re: ResourceAccessGate (SLING-2698))

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

Hi Angela,

you're definitely missinterpreting my sentences - I care, but even
more important the Sling community cares a lot about security.

Sure, we can always do better - but it's important that we work
together as a community on all aspects of Sling - security is of
course an important part here, but we should also think about the
goals of Sling and most importantly our users - of course not
sacrificing security (This is not targeted directly at you, but just a
general statement).

And it's good that you, Lars and others share your experience and
concers, that's really appreciated. Maybe I got a little bit overboard
with my comments, as I'm really disappointed how this discussion went.

And as Ian said, if you are aware of any other security problems which
we didn't noticed, please share your insight (either publically or
private)

Thanks
Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Sling and Security (was: Re: ResourceAccessGate (SLING-2698))

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

On Thu, Mar 7, 2013 at 12:55 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> ...If there are other areas where its possible, with ease to create
> critical security issues, then I think we must address those
> immediately.
>
> Please share, ideally on list.
> If you think its not for public list consumption please send a message
> to sling-private so the issue can be added to the normal cert
> procedure...

Note that http://sling.apache.org/project-information/security.html
describes how to report security issues without making them public.

-Bertrand

Re: Sling and Security (was: Re: ResourceAccessGate (SLING-2698))

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

On 7 March 2013 04:31, Angela Schreiber <an...@adobe.com> wrote:
> hi carsten
>
>> Finally, although this feature is optional and has no impact if not
>> used, there are valid concerns that this might be easily abused. But
>> we can't prevent anyone from abusing stuff and we already have various
>> places where people do funny things.
>
>
> just to make it very clear: it's not only that people make funny
> things. it's infinitely easy to create critical security issues
> with sling without noticing and i hope you are aware of this.
>
> i don't want to spread FUD here but IMHO it's time that the sling
> community is taking security concerns serious and thrives for a
> project that is secure by default.
>
> statements like "Features can be abused - no matter what we do"
> will likely create the impression that you don't really care.
>
> kind regards
> angela

Hi,

IMHO:
We should not be adding features that make it easy to bypass security,
other than the necessary and very well known
SlingRepository.loginAdministrative(..) method. I assume that is what
Carsten is referencing ?

also IMHO:
Once it is easy for a trusted and authorised 3rd party developer to
add executable code into a JVM all bets are off, even in OSGi. Unless
the Java security manager is enabled  and policies configured, which
we all know is fiendishly hard to get right, javax.reflect and
net.sf.cglib can be used to drill deep into the internals of the
implementation of any bundle.

Having said that:
I strongly agree that Sling as a community should not be providing any
features (beyond the necessary feature mentioned above) that weaken
breach or bypass the intrinsic security provided by underlying
repository.

As for  SlingRepository.loginAdministrative(..), we have to remain
vigilant and provide tools to ensure it is only used when absolutely
necessary. ( there are 15 classes in Sling where this is used in some
way, excluding contrib, samples and tests)

If there are other areas where its possible, with ease to create
critical security issues, then I think we must address those
immediately.

Please share, ideally on list.
If you think its not for public list consumption please send a message
to sling-private so the issue can be added to the normal cert
procedure.

Best Regards,
Ian