You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Nikolaus Rosenmayr <n....@gmx.at> on 2002/07/29 23:47:43 UTC
security question regarding session user in pull model
Hi,
although I am a newbie with turbine, I already stepped deep into T3 code as I am building a big servlet-application with it. Security has always been a major concern to me, so please, may someone respond to the following issue. I may be wrong and have overseen some code, please tell me if that is the case.
My application is "yet-another" content-management-system (CMS) for a web site, based on T3, Velocity and OJB, and it will be used in an academic area with a great amount of users, designers and editors. Designers and editors should be able to upload their own templates to change the display-style of their own content. Taking the advantage of the pull model, not every template has to be backed with java modules - there exists a global database access object within the template context. This database access object enables the template designer to create new templates without bothering the application programmer to add a module that puts all required data into the template context. Instead the template designer can simply PULL all needed stuff from this global database access object. This database access objects takes the current session user into account when pull-requests are handled. (Access is denied if the current session user has insufficient rights.)
Since neither the interface org.apache.fulcrum.security.entity.User nor the implementation at org.apache.fulcrum.security.impl.db.entity.TurbineUser has a method to retrieve the user ID, validating the session user is based on the username (user.getUserName()) A malicious template designer may gain more rights if he uses (see "PS" below why the application can not use turbines ACL only)
$data.getUserFromSession().setUserName("newUserName")
$data.save()
Even if I check the user object against "hasLoggedIn()" it does not matter since it returns true in this case. The user entity is the same, only the user name has changed.
If a malicious template designer ever manage to fetch another user object from the database, he may exchange it with the current session user:
#set ($newUser = $dbAccess.getUserByLoginName("admin") )
$newUser.setHasLoggedIn(true);
$data.setUser($newUser)
$data.save()
So be careful with PULL service to never expose any method that retrieves a new user object from the database.
Even if every method of the database access object checks the access control list of the session user, the template designer may wreck the application (DoS). Permissions are heavily based on names in Turbine (am I right?). I looked at the actual implementation about setting and retrieving ACL from the session. I think this might be a way to alter the names of permissions so that other application code may deny access to other users (or administrators).
#set ($ext = ".ha")
#foreach ($permission in $data.getACL().getPermissions().elements())
$permission.rename($permission.getName() + $ext)
$permission.save()
#set ( $ext = $ext + ".ha" )
#end
I did not found any code that checks, if this renaming has been done by an authorized session user. Did I miss it? I did not find any logging code either that would write a message to the log that a specific user has changed the permission names. I admit that the template is only able to change session user's permissions, but that is enough to be concerned. (The same applies to roles)
(DISCLAIMER: I did NOT test the above code - it is just an idea!!)
Conclusion: If all this is true, I think this is a weakness. The applications programmer must be extremely careful when using the pull service in conjunction with user uploaded templates and should not rely on the names of permissions and roles. I decided that each template must be certified by an administrator. No user is allowed to upload templates on his own. But this is no desirable situation since the admin must be asked for every change in the template code, even during testing end developing phases. This means a lot of time and human resources and a lot of costs.
I think, I do not have enough information about T3 to change the code appropriate and provide a patch. If this is really a security issue then some checks should be added :) Is someone working on it already? Will this behaviour be changed in the future?
I am not a developer of Turbine and there is still a long way to go to learn T3 to become one, but I will participate in a discussion if I am of some help.
My concern about the security will not prevent me from using this very cool framework. I love it :) and will circumvent this weakness with my own security layer.
Regards,
Nikolaus
By the way: I did not find the source for org.apache.fulcrum.security.impl.db.entity.BaseTurbineUser in the CVS tree but this class seems to be the super class of org.apache.fulcrum.security.impl.db.entity.TurbineUser.
PS: (feature request:) I have to implement my own security layer because Turbine can not cope with security settings that are data dependent. Fe. Assume a web based forum with various categories. Each category has its own manager. All categories are instance of the same class (Category) but only the manager is allowed to remove postings. So security is closely related to the instance of Category and not to the class Category. I did not find a way to manage permissions in an instance-based manner in turbine other that to add a separately named permission for every instance. This seems acceptable in this example but is not acceptable when handling thousands of texts in a content-management-system, written by many authors and managed by different editors. I need a way to set permissions like file systems do. (Fe. like XFS or simpler like ext2)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: security question regarding session user in pull model
Posted by John McNally <jm...@collab.net>.
I sent Will the code sample. There are other examples posted to the
velocity dev list, if anyone wants more than my word for it. The basic
problem is that velocity allows one to access ClassLoaders
($someObj.Class.Classloader). After that a little creativity will let
you do pretty much anything you want.
So if you are allowing untrusted templates to be rendered, you should
treat the the velocity package as untrusted java code. You can then use
java's security mechanisms to protect your system, if these security
mechanisms are adequate.
There was talk about making velocity not allow method calls on a
ClassLoader. If you would like to know how this is progressing please
search the archives and ask questions over there.
Assuming velocity code is secure, what about turbine's security
service? I doubt that switching from using a String non-pk field to an
integer pk field is going to result in gains in security. At least not
by itself. It will take a design that is very much concerned with
untrusted developers, which as you point out fulcrum's security service
was not designed with this goal.
john mcnally
On Mon, 2002-07-29 at 21:58, Will Glass-Husain wrote:
> John,
>
> Our system is based around untrusted users uploading Velocity pages and
> running mini applications (all within a shared VM).
>
> Can you be more specific about the security issues with VTL? I'd like to
> see that 5 line VTL to be honest. (Perhaps you might send it in a personal
> email if that seems better).
>
> Thanks, WILL
>
> At 07:50 PM 7/29/02 -0700, you wrote:
> >A general purpose tool like velocity based on reflection cannot be used
> >in a setting that cannot trust the code being run. It is possible
> >starting from any object in the context to shutdown the jvm. I have
> >written a template that does this, it was about 5 lines of vtl. I'm
> >guessing that it could be possible to do more harmful things like
> >erasing the hd.
> >
> >I do not know if there is a way to use java's security that limits the
> >possible things code is allowed to do, to help in this situation. There
> >are also other template systems like Tea that say they are able to
> >run/render untrusted templates. FreeMarker also provides a model that
> >might offer protection, though I think they might be adding reflection
> >as a possibility. (I have to say based on a flame-war thread awhile
> >back on the velocity list that you should make sure you really, really
> >like the FreeMarker technology before developing with it.)
> >
> >john mcnally
> >
> >
> >On Mon, 2002-07-29 at 14:47, Nikolaus Rosenmayr wrote:
> > > Hi,
> > >
> > > although I am a newbie with turbine, I already stepped deep into T3
> > code as I am building a big servlet-application with it. Security has
> > always been a major concern to me, so please, may someone respond to the
> > following issue. I may be wrong and have overseen some code, please tell
> > me if that is the case.
> > >
> > > My application is "yet-another" content-management-system (CMS) for a
> > web site, based on T3, Velocity and OJB, and it will be used in an
> > academic area with a great amount of users, designers and editors.
> > Designers and editors should be able to upload their own templates to
> > change the display-style of their own content. Taking the advantage of
> > the pull model, not every template has to be backed with java modules -
> > there exists a global database access object within the template context.
> > This database access object enables the template designer to create new
> > templates without bothering the application programmer to add a module
> > that puts all required data into the template context. Instead the
> > template designer can simply PULL all needed stuff from this global
> > database access object. This database access objects takes the current
> > session user into account when pull-requests are handled. (Access is
> > denied if the current session user has insufficient rights.)
> > >
> > > Since neither the interface org.apache.fulcrum.security.entity.User nor
> > the implementation at
> > org.apache.fulcrum.security.impl.db.entity.TurbineUser has a method to
> > retrieve the user ID, validating the session user is based on the
> > username (user.getUserName()) A malicious template designer may gain
> > more rights if he uses (see "PS" below why the application can not use
> > turbines ACL only)
> > >
> > > $data.getUserFromSession().setUserName("newUserName")
> > > $data.save()
> > >
> > > Even if I check the user object against "hasLoggedIn()" it does not
> > matter since it returns true in this case. The user entity is the same,
> > only the user name has changed.
> > > If a malicious template designer ever manage to fetch another user
> > object from the database, he may exchange it with the current session user:
> > >
> > > #set ($newUser = $dbAccess.getUserByLoginName("admin") )
> > > $newUser.setHasLoggedIn(true);
> > > $data.setUser($newUser)
> > > $data.save()
> > >
> > > So be careful with PULL service to never expose any method that
> > retrieves a new user object from the database.
> > >
> > > Even if every method of the database access object checks the access
> > control list of the session user, the template designer may wreck the
> > application (DoS). Permissions are heavily based on names in Turbine (am
> > I right?). I looked at the actual implementation about setting and
> > retrieving ACL from the session. I think this might be a way to alter the
> > names of permissions so that other application code may deny access to
> > other users (or administrators).
> > >
> > > #set ($ext = ".ha")
> > > #foreach ($permission in $data.getACL().getPermissions().elements())
> > > $permission.rename($permission.getName() + $ext)
> > > $permission.save()
> > > #set ( $ext = $ext + ".ha" )
> > > #end
> > >
> > > I did not found any code that checks, if this renaming has been done by
> > an authorized session user. Did I miss it? I did not find any logging
> > code either that would write a message to the log that a specific user
> > has changed the permission names. I admit that the template is only able
> > to change session user's permissions, but that is enough to be concerned.
> > (The same applies to roles)
> > >
> > > (DISCLAIMER: I did NOT test the above code - it is just an idea!!)
> > >
> > > Conclusion: If all this is true, I think this is a weakness. The
> > applications programmer must be extremely careful when using the pull
> > service in conjunction with user uploaded templates and should not rely
> > on the names of permissions and roles. I decided that each template must
> > be certified by an administrator. No user is allowed to upload templates
> > on his own. But this is no desirable situation since the admin must be
> > asked for every change in the template code, even during testing end
> > developing phases. This means a lot of time and human resources and a lot
> > of costs.
> > >
> > > I think, I do not have enough information about T3 to change the code
> > appropriate and provide a patch. If this is really a security issue then
> > some checks should be added :) Is someone working on it already? Will
> > this behaviour be changed in the future?
> > > I am not a developer of Turbine and there is still a long way to go to
> > learn T3 to become one, but I will participate in a discussion if I am of
> > some help.
> > >
> > > My concern about the security will not prevent me from using this very
> > cool framework. I love it :) and will circumvent this weakness with my
> > own security layer.
> > >
> > > Regards,
> > > Nikolaus
> > >
> > > By the way: I did not find the source for
> > org.apache.fulcrum.security.impl.db.entity.BaseTurbineUser in the CVS
> > tree but this class seems to be the super class
> > of org.apache.fulcrum.security.impl.db.entity.TurbineUser.
> > >
> > > PS: (feature request:) I have to implement my own security layer
> > because Turbine can not cope with security settings that are data
> > dependent. Fe. Assume a web based forum with various categories. Each
> > category has its own manager. All categories are instance of the same
> > class (Category) but only the manager is allowed to remove postings. So
> > security is closely related to the instance of Category and not to the
> > class Category. I did not find a way to manage permissions in an
> > instance-based manner in turbine other that to add a separately named
> > permission for every instance. This seems acceptable in this example but
> > is not acceptable when handling thousands of texts in a
> > content-management-system, written by many authors and managed by
> > different editors. I need a way to set permissions like file systems do.
> > (Fe. like XFS or simpler like ext2)
> > >
> > >
> > > --
> > > To unsubscribe,
> > e-mail: <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: security question regarding session user in pull model
Posted by Will Glass-Husain <wg...@forio.com>.
John,
Our system is based around untrusted users uploading Velocity pages and
running mini applications (all within a shared VM).
Can you be more specific about the security issues with VTL? I'd like to
see that 5 line VTL to be honest. (Perhaps you might send it in a personal
email if that seems better).
Thanks, WILL
At 07:50 PM 7/29/02 -0700, you wrote:
>A general purpose tool like velocity based on reflection cannot be used
>in a setting that cannot trust the code being run. It is possible
>starting from any object in the context to shutdown the jvm. I have
>written a template that does this, it was about 5 lines of vtl. I'm
>guessing that it could be possible to do more harmful things like
>erasing the hd.
>
>I do not know if there is a way to use java's security that limits the
>possible things code is allowed to do, to help in this situation. There
>are also other template systems like Tea that say they are able to
>run/render untrusted templates. FreeMarker also provides a model that
>might offer protection, though I think they might be adding reflection
>as a possibility. (I have to say based on a flame-war thread awhile
>back on the velocity list that you should make sure you really, really
>like the FreeMarker technology before developing with it.)
>
>john mcnally
>
>
>On Mon, 2002-07-29 at 14:47, Nikolaus Rosenmayr wrote:
> > Hi,
> >
> > although I am a newbie with turbine, I already stepped deep into T3
> code as I am building a big servlet-application with it. Security has
> always been a major concern to me, so please, may someone respond to the
> following issue. I may be wrong and have overseen some code, please tell
> me if that is the case.
> >
> > My application is "yet-another" content-management-system (CMS) for a
> web site, based on T3, Velocity and OJB, and it will be used in an
> academic area with a great amount of users, designers and editors.
> Designers and editors should be able to upload their own templates to
> change the display-style of their own content. Taking the advantage of
> the pull model, not every template has to be backed with java modules -
> there exists a global database access object within the template context.
> This database access object enables the template designer to create new
> templates without bothering the application programmer to add a module
> that puts all required data into the template context. Instead the
> template designer can simply PULL all needed stuff from this global
> database access object. This database access objects takes the current
> session user into account when pull-requests are handled. (Access is
> denied if the current session user has insufficient rights.)
> >
> > Since neither the interface org.apache.fulcrum.security.entity.User nor
> the implementation at
> org.apache.fulcrum.security.impl.db.entity.TurbineUser has a method to
> retrieve the user ID, validating the session user is based on the
> username (user.getUserName()) A malicious template designer may gain
> more rights if he uses (see "PS" below why the application can not use
> turbines ACL only)
> >
> > $data.getUserFromSession().setUserName("newUserName")
> > $data.save()
> >
> > Even if I check the user object against "hasLoggedIn()" it does not
> matter since it returns true in this case. The user entity is the same,
> only the user name has changed.
> > If a malicious template designer ever manage to fetch another user
> object from the database, he may exchange it with the current session user:
> >
> > #set ($newUser = $dbAccess.getUserByLoginName("admin") )
> > $newUser.setHasLoggedIn(true);
> > $data.setUser($newUser)
> > $data.save()
> >
> > So be careful with PULL service to never expose any method that
> retrieves a new user object from the database.
> >
> > Even if every method of the database access object checks the access
> control list of the session user, the template designer may wreck the
> application (DoS). Permissions are heavily based on names in Turbine (am
> I right?). I looked at the actual implementation about setting and
> retrieving ACL from the session. I think this might be a way to alter the
> names of permissions so that other application code may deny access to
> other users (or administrators).
> >
> > #set ($ext = ".ha")
> > #foreach ($permission in $data.getACL().getPermissions().elements())
> > $permission.rename($permission.getName() + $ext)
> > $permission.save()
> > #set ( $ext = $ext + ".ha" )
> > #end
> >
> > I did not found any code that checks, if this renaming has been done by
> an authorized session user. Did I miss it? I did not find any logging
> code either that would write a message to the log that a specific user
> has changed the permission names. I admit that the template is only able
> to change session user's permissions, but that is enough to be concerned.
> (The same applies to roles)
> >
> > (DISCLAIMER: I did NOT test the above code - it is just an idea!!)
> >
> > Conclusion: If all this is true, I think this is a weakness. The
> applications programmer must be extremely careful when using the pull
> service in conjunction with user uploaded templates and should not rely
> on the names of permissions and roles. I decided that each template must
> be certified by an administrator. No user is allowed to upload templates
> on his own. But this is no desirable situation since the admin must be
> asked for every change in the template code, even during testing end
> developing phases. This means a lot of time and human resources and a lot
> of costs.
> >
> > I think, I do not have enough information about T3 to change the code
> appropriate and provide a patch. If this is really a security issue then
> some checks should be added :) Is someone working on it already? Will
> this behaviour be changed in the future?
> > I am not a developer of Turbine and there is still a long way to go to
> learn T3 to become one, but I will participate in a discussion if I am of
> some help.
> >
> > My concern about the security will not prevent me from using this very
> cool framework. I love it :) and will circumvent this weakness with my
> own security layer.
> >
> > Regards,
> > Nikolaus
> >
> > By the way: I did not find the source for
> org.apache.fulcrum.security.impl.db.entity.BaseTurbineUser in the CVS
> tree but this class seems to be the super class
> of org.apache.fulcrum.security.impl.db.entity.TurbineUser.
> >
> > PS: (feature request:) I have to implement my own security layer
> because Turbine can not cope with security settings that are data
> dependent. Fe. Assume a web based forum with various categories. Each
> category has its own manager. All categories are instance of the same
> class (Category) but only the manager is allowed to remove postings. So
> security is closely related to the instance of Category and not to the
> class Category. I did not find a way to manage permissions in an
> instance-based manner in turbine other that to add a separately named
> permission for every instance. This seems acceptable in this example but
> is not acceptable when handling thousands of texts in a
> content-management-system, written by many authors and managed by
> different editors. I need a way to set permissions like file systems do.
> (Fe. like XFS or simpler like ext2)
> >
> >
> > --
> > To unsubscribe,
> e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: security question regarding session user in pull model
Posted by John McNally <jm...@collab.net>.
A general purpose tool like velocity based on reflection cannot be used
in a setting that cannot trust the code being run. It is possible
starting from any object in the context to shutdown the jvm. I have
written a template that does this, it was about 5 lines of vtl. I'm
guessing that it could be possible to do more harmful things like
erasing the hd.
I do not know if there is a way to use java's security that limits the
possible things code is allowed to do, to help in this situation. There
are also other template systems like Tea that say they are able to
run/render untrusted templates. FreeMarker also provides a model that
might offer protection, though I think they might be adding reflection
as a possibility. (I have to say based on a flame-war thread awhile
back on the velocity list that you should make sure you really, really
like the FreeMarker technology before developing with it.)
john mcnally
On Mon, 2002-07-29 at 14:47, Nikolaus Rosenmayr wrote:
> Hi,
>
> although I am a newbie with turbine, I already stepped deep into T3 code as I am building a big servlet-application with it. Security has always been a major concern to me, so please, may someone respond to the following issue. I may be wrong and have overseen some code, please tell me if that is the case.
>
> My application is "yet-another" content-management-system (CMS) for a web site, based on T3, Velocity and OJB, and it will be used in an academic area with a great amount of users, designers and editors. Designers and editors should be able to upload their own templates to change the display-style of their own content. Taking the advantage of the pull model, not every template has to be backed with java modules - there exists a global database access object within the template context. This database access object enables the template designer to create new templates without bothering the application programmer to add a module that puts all required data into the template context. Instead the template designer can simply PULL all needed stuff from this global database access object. This database access objects takes the current session user into account when pull-requests are handled. (Access is denied if the current session user has insufficient rights.)
>
> Since neither the interface org.apache.fulcrum.security.entity.User nor the implementation at org.apache.fulcrum.security.impl.db.entity.TurbineUser has a method to retrieve the user ID, validating the session user is based on the username (user.getUserName()) A malicious template designer may gain more rights if he uses (see "PS" below why the application can not use turbines ACL only)
>
> $data.getUserFromSession().setUserName("newUserName")
> $data.save()
>
> Even if I check the user object against "hasLoggedIn()" it does not matter since it returns true in this case. The user entity is the same, only the user name has changed.
> If a malicious template designer ever manage to fetch another user object from the database, he may exchange it with the current session user:
>
> #set ($newUser = $dbAccess.getUserByLoginName("admin") )
> $newUser.setHasLoggedIn(true);
> $data.setUser($newUser)
> $data.save()
>
> So be careful with PULL service to never expose any method that retrieves a new user object from the database.
>
> Even if every method of the database access object checks the access control list of the session user, the template designer may wreck the application (DoS). Permissions are heavily based on names in Turbine (am I right?). I looked at the actual implementation about setting and retrieving ACL from the session. I think this might be a way to alter the names of permissions so that other application code may deny access to other users (or administrators).
>
> #set ($ext = ".ha")
> #foreach ($permission in $data.getACL().getPermissions().elements())
> $permission.rename($permission.getName() + $ext)
> $permission.save()
> #set ( $ext = $ext + ".ha" )
> #end
>
> I did not found any code that checks, if this renaming has been done by an authorized session user. Did I miss it? I did not find any logging code either that would write a message to the log that a specific user has changed the permission names. I admit that the template is only able to change session user's permissions, but that is enough to be concerned. (The same applies to roles)
>
> (DISCLAIMER: I did NOT test the above code - it is just an idea!!)
>
> Conclusion: If all this is true, I think this is a weakness. The applications programmer must be extremely careful when using the pull service in conjunction with user uploaded templates and should not rely on the names of permissions and roles. I decided that each template must be certified by an administrator. No user is allowed to upload templates on his own. But this is no desirable situation since the admin must be asked for every change in the template code, even during testing end developing phases. This means a lot of time and human resources and a lot of costs.
>
> I think, I do not have enough information about T3 to change the code appropriate and provide a patch. If this is really a security issue then some checks should be added :) Is someone working on it already? Will this behaviour be changed in the future?
> I am not a developer of Turbine and there is still a long way to go to learn T3 to become one, but I will participate in a discussion if I am of some help.
>
> My concern about the security will not prevent me from using this very cool framework. I love it :) and will circumvent this weakness with my own security layer.
>
> Regards,
> Nikolaus
>
> By the way: I did not find the source for org.apache.fulcrum.security.impl.db.entity.BaseTurbineUser in the CVS tree but this class seems to be the super class of org.apache.fulcrum.security.impl.db.entity.TurbineUser.
>
> PS: (feature request:) I have to implement my own security layer because Turbine can not cope with security settings that are data dependent. Fe. Assume a web based forum with various categories. Each category has its own manager. All categories are instance of the same class (Category) but only the manager is allowed to remove postings. So security is closely related to the instance of Category and not to the class Category. I did not find a way to manage permissions in an instance-based manner in turbine other that to add a separately named permission for every instance. This seems acceptable in this example but is not acceptable when handling thousands of texts in a content-management-system, written by many authors and managed by different editors. I need a way to set permissions like file systems do. (Fe. like XFS or simpler like ext2)
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: security question regarding session user in pull model
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-07-30 at 11:45, Nikolaus Rosenmayr wrote:
> Hi Jon,
>
> thank you for your suggestion. This sounds great, but I do not see how this may be accomplished easily.
I think it can't. Turbine is not oriented at all to securing the use of
untrusted templates.
> org.apache.turbine.modules.Module adds the rundata object to the context in a static method named
> "getTemplateContext". This static method is called from many of
pipeline modules and even the renderer. I would have to rewrite these
pipeline modules and the renderer and all other code that instantiate
the renderer for there is no property to tell which rendering class to
use.
It should be possible to extend the renderer and only having to rewrite
a few methods tho'
> (I will do if this is the way but I am thinking of other ways, too).
Patching Module is risky because this may break other applications
requiring this rundata object in the template context.
> "getTemplateContext" method calls the rundata service. If I change the
rundata service to provide my own implementation of the RunData interface
(by changing some properties) then this has side effects on all other parts
of the turbine framework. Currently I am checking if the rest of the framework
relies on retrieving the user object from the rundata but I think it does.
So my implementation of the RunData interface must not return an invalid user
object or ACL when asked to provide some. There is no possibility to check
if the rundata is called from inside or outside the template.
> When it comes to that point rewriting a lot of turbine code seems to be necessary
for this project (and that is not desirable :) ) and what about other projects? Why
then use a framework if all has to be done over and over again? (I am not questioning
the use of Turbine, the contrary is true - I love it and it has a lot of advantages
over other frameworks!)
> At the moment, from my point of view the only way to go seems to be to ignore the
security implementation of Fulcrum.
hmm. Works well for me.
> Instead I will put another user object, that uses
a much more secure implementation, to the session data and build my own security layer.
This will use the turbine tables but the security checks will be based on IDs rather
than texts - whenever a user changes the permission text the ID stays the same. (Or I
will use other tables if my checks are based on texts, too)
> If I learn enough of Turbine/Fulcrum to see how I can integrate my security layer
with Fulcrum and Turbine I will do so and will send it to this list. This will not
happen before September.
that'd be interesting.
> If someone has different ideas I will appreciate reading them.
1) it seems like it is more a concern for velocity than for turbine to
handle untrusted templates.
2) I have a CMS setup similar to what you describe that uses some parts
of Turbine as well. Modification of templates is handled via a GUI
client though, which has its own server with robust functionality.
3) Turbine security in my experience is somewhat oriented at allowing
users to either access data or not, and is somewhat cumbersome to use
for more complex permission systems. I have written my own security
layer, with which Turbine works together quite nicely.
4) sorry, can't be more specific, it's all in-house commercial stuff
atm.
cheers,
Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: security question regarding session user in pull model
Posted by Nikolaus Rosenmayr <n....@gmx.at>.
Hi Jon,
you misunderstood me! I want to improve Turbine and I will send a patch as soon as I have satisfying solution. (My "paranoia" is keeping my servers secure) But I have the feeling that this would include many changes and I think it is worth discussing. Then others and me are able to find a good solution. If I have one I will post it, as soon as I have finished it. (But this will take some time)
regards
Niki
----- Original Message -----
From: "Jon Scott Stevens" <jo...@latchkey.com>
To: "turbine-dev" <tu...@jakarta.apache.org>
Sent: Tuesday, July 30, 2002 6:52 PM
Subject: Re: security question regarding session user in pull model
> You are thinking incorrectly. Submit a patch to improve the functionality of
> the classes. That is the point of Turbine...it is a group collaboration.
>
> There is no way for us to create something that works 100% for every single
> case...especially cases based on paranoia. If you think that that is to much
> work for you or to difficult, then it might be a good idea to look elsewhere
> as Leo said, Turbine's main focus is not on security at the template layer.
>
> As for testing with other applications, it is easy to test with Scarab and,
> if it works with Scarab, it will work with anything else.
>
> Good luck with your project.
>
> -jon
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: security question regarding session user in pull model
Posted by Jon Scott Stevens <jo...@latchkey.com>.
You are thinking incorrectly. Submit a patch to improve the functionality of
the classes. That is the point of Turbine...it is a group collaboration.
There is no way for us to create something that works 100% for every single
case...especially cases based on paranoia. If you think that that is to much
work for you or to difficult, then it might be a good idea to look elsewhere
as Leo said, Turbine's main focus is not on security at the template layer.
As for testing with other applications, it is easy to test with Scarab and,
if it works with Scarab, it will work with anything else.
Good luck with your project.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: security question regarding session user in pull model
Posted by Nikolaus Rosenmayr <n....@gmx.at>.
Hi Jon,
thank you for your suggestion. This sounds great, but I do not see how this may be accomplished easily.
org.apache.turbine.modules.Module adds the rundata object to the context in a static method named "getTemplateContext". This static method is called from many of pipeline modules and even the renderer. I would have to rewrite these pipeline modules and the renderer and all other code that instantiate the renderer for there is no property to tell which rendering class to use. (I will do if this is the way but I am thinking of other ways, too). Patching Module is risky because this may break other applications requiring this rundata object in the template context.
"getTemplateContext" method calls the rundata service. If I change the rundata service to provide my own implementation of the RunData interface (by changing some properties) then this has side effects on all other parts of the turbine framework. Currently I am checking if the rest of the framework relies on retrieving the user object from the rundata but I think it does. So my implementation of the RunData interface must not return an invalid user object or ACL when asked to provide some. There is no possibility to check if the rundata is called from inside or outside the template.
When it comes to that point rewriting a lot of turbine code seems to be necessary for this project (and that is not desirable :) ) and what about other projects? Why then use a framework if all has to be done over and over again? (I am not questioning the use of Turbine, the contrary is true - I love it and it has a lot of advantages over other frameworks!)
At the moment, from my point of view the only way to go seems to be to ignore the security implementation of Fulcrum. Instead I will put another user object, that uses a much more secure implementation, to the session data and build my own security layer. This will use the turbine tables but the security checks will be based on IDs rather than texts - whenever a user changes the permission text the ID stays the same. (Or I will use other tables if my checks are based on texts, too)
If I learn enough of Turbine/Fulcrum to see how I can integrate my security layer with Fulcrum and Turbine I will do so and will send it to this list. This will not happen before September.
If someone has different ideas I will appreciate reading them.
best regards
Niki
----- Original Message -----
From: "Jon Scott Stevens" <jo...@latchkey.com>
To: "turbine-dev" <tu...@jakarta.apache.org>
Sent: Tuesday, July 30, 2002 2:06 AM
Subject: Re: security question regarding session user in pull model
> If you are that worried that your employees might sabotage the system, then
> don't put the $data object (or fill in the blank object) into the context.
> Instead, you can write a small wrapper around that object and only provide
> the methods that you want to provide.
>
> -jon
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: security question regarding session user in pull model
Posted by Jon Scott Stevens <jo...@latchkey.com>.
If you are that worried that your employees might sabotage the system, then
don't put the $data object (or fill in the blank object) into the context.
Instead, you can write a small wrapper around that object and only provide
the methods that you want to provide.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>