You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@freemarker.apache.org by Daniel Dekany <da...@gmail.com> on 2020/10/11 18:42:34 UTC

FreeMarker generator security related configuration defaults

I noticed that ?api and ?new are by default disabled in
freemarker-generator. However, freemarker-generator is inherently unsafe,
as it has tools.freemarker.objectConstructor, and tools.freemarker.statics.
For a command-line tool that's probably fine, but then above two
configuration settings should be left on their convenient defaults as well.

In general, allowing someone to specify arbitrary command line arguments
to freemarker-generator CLI means that they can do pretty much anything (as
they can provide an arbitrary template with the -i option, then access the
tools). Again, I think such risk is expected from a command line tool, but
it's better if we are conscious about this.

-- 
Best regards,
Daniel Dekany

Re: FreeMarker generator security related configuration defaults

Posted by Jacques Le Roux <ja...@les7arts.com>.
OK, no problem with me

Le 17/10/2020 à 20:48, Daniel Dekany a écrit :
> What I'm saying is that we should enable those unsafe features, as this
> command line tool is "unsafe" anyway. I quoted unsafe, because a command
> line tool like this is not something that sane developer would expose to
> untrusted users. (It's like saying rm is unsafe... yeah, it has to be,
> something needs to be able to delete stuff.)
>
> On Sat, Oct 17, 2020 at 8:32 PM Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Thanks Daniel,
>>
>> Indeed, these possible security issues are not obvious to everyone.
>> Disabling unsafe features is indeed a convenient way to make them prominent.
>>
>> Jacques
>>
>> Le 11/10/2020 à 20:42, Daniel Dekany a écrit :
>>> I noticed that ?api and ?new are by default disabled in
>>> freemarker-generator. However, freemarker-generator is inherently unsafe,
>>> as it has tools.freemarker.objectConstructor, and
>> tools.freemarker.statics.
>>> For a command-line tool that's probably fine, but then above two
>>> configuration settings should be left on their convenient defaults as
>> well.
>>> In general, allowing someone to specify arbitrary command line arguments
>>> to freemarker-generator CLI means that they can do pretty much anything
>> (as
>>> they can provide an arbitrary template with the -i option, then access
>> the
>>> tools). Again, I think such risk is expected from a command line tool,
>> but
>>> it's better if we are conscious about this.
>>>
>

Re: FreeMarker generator security related configuration defaults

Posted by Daniel Dekany <da...@gmail.com>.
What I'm saying is that we should enable those unsafe features, as this
command line tool is "unsafe" anyway. I quoted unsafe, because a command
line tool like this is not something that sane developer would expose to
untrusted users. (It's like saying rm is unsafe... yeah, it has to be,
something needs to be able to delete stuff.)

On Sat, Oct 17, 2020 at 8:32 PM Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Thanks Daniel,
>
> Indeed, these possible security issues are not obvious to everyone.
> Disabling unsafe features is indeed a convenient way to make them prominent.
>
> Jacques
>
> Le 11/10/2020 à 20:42, Daniel Dekany a écrit :
> > I noticed that ?api and ?new are by default disabled in
> > freemarker-generator. However, freemarker-generator is inherently unsafe,
> > as it has tools.freemarker.objectConstructor, and
> tools.freemarker.statics.
> > For a command-line tool that's probably fine, but then above two
> > configuration settings should be left on their convenient defaults as
> well.
> >
> > In general, allowing someone to specify arbitrary command line arguments
> > to freemarker-generator CLI means that they can do pretty much anything
> (as
> > they can provide an arbitrary template with the -i option, then access
> the
> > tools). Again, I think such risk is expected from a command line tool,
> but
> > it's better if we are conscious about this.
> >
>


-- 
Best regards,
Daniel Dekany

Re: FreeMarker generator security related configuration defaults

Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks Daniel,

Indeed, these possible security issues are not obvious to everyone. Disabling unsafe features is indeed a convenient way to make them prominent.

Jacques

Le 11/10/2020 à 20:42, Daniel Dekany a écrit :
> I noticed that ?api and ?new are by default disabled in
> freemarker-generator. However, freemarker-generator is inherently unsafe,
> as it has tools.freemarker.objectConstructor, and tools.freemarker.statics.
> For a command-line tool that's probably fine, but then above two
> configuration settings should be left on their convenient defaults as well.
>
> In general, allowing someone to specify arbitrary command line arguments
> to freemarker-generator CLI means that they can do pretty much anything (as
> they can provide an arbitrary template with the -i option, then access the
> tools). Again, I think such risk is expected from a command line tool, but
> it's better if we are conscious about this.
>

Re: FreeMarker generator security related configuration defaults

Posted by Daniel Dekany <da...@gmail.com>.
I don't follow. Is that a yes?

So, what I'm saying is that freemarker-generator is inherently "unsafe",
like any power-user/developer tool is. And also you add tools to it that
are also "unsafe" (which is fine). So there's no point in deviating from
the FreeMarker defaults, whichare, historically, about convenience. Also
the defaults won't change in 2.x, because of backward compatibility (unless
you specifically ask for some high incompatibleImprovements, like 2.4.x).
So it won't break because of upgrading the FreeMarker dependency.

On Wed, Oct 28, 2020 at 9:27 PM Siegfried Goeschl <
siegfried.goeschl@gmail.com> wrote:

> Hi Daniel,
>
> I think the outcome was that we might use more secure default settings for
> FreeMarker and so I switched to the secure settings to see if I would need
> them
>
> Thanks in advance,
>
> Siegfried Goeschl
>
>
> > On 21.10.2020, at 08:01, Daniel Dekany <da...@gmail.com> wrote:
> >
> > Does that mean that you agree that we should leave them on the actual
> > FreeMarker 2.3.x defaults (?api enabled, ?new set to "safer")?
> >
> > On Mon, Oct 19, 2020 at 7:31 PM Siegfried Goeschl <
> > siegfried.goeschl@gmail.com> wrote:
> >
> >> Hi Daniel,
> >>
> >> yes, I disabled them since I assume that they will be the default
> settings
> >>
> >> Thanks in advance
> >>
> >> Siegfried Goeschl
> >>
> >>> On 11.10.2020, at 20:42, Daniel Dekany <da...@gmail.com>
> wrote:
> >>>
> >>> I noticed that ?api and ?new are by default disabled in
> >>> freemarker-generator. However, freemarker-generator is inherently
> unsafe,
> >>> as it has tools.freemarker.objectConstructor, and
> >> tools.freemarker.statics.
> >>> For a command-line tool that's probably fine, but then above two
> >>> configuration settings should be left on their convenient defaults as
> >> well.
> >>>
> >>> In general, allowing someone to specify arbitrary command line
> arguments
> >>> to freemarker-generator CLI means that they can do pretty much anything
> >> (as
> >>> they can provide an arbitrary template with the -i option, then access
> >> the
> >>> tools). Again, I think such risk is expected from a command line tool,
> >> but
> >>> it's better if we are conscious about this.
> >>>
> >>> --
> >>> Best regards,
> >>> Daniel Dekany
> >>
> >>
> >
> > --
> > Best regards,
> > Daniel Dekany
>
>

-- 
Best regards,
Daniel Dekany

Re: FreeMarker generator security related configuration defaults

Posted by Siegfried Goeschl <si...@gmail.com>.
Hi Daniel,

I think the outcome was that we might use more secure default settings for FreeMarker and so I switched to the secure settings to see if I would need them

Thanks in advance, 

Siegfried Goeschl


> On 21.10.2020, at 08:01, Daniel Dekany <da...@gmail.com> wrote:
> 
> Does that mean that you agree that we should leave them on the actual
> FreeMarker 2.3.x defaults (?api enabled, ?new set to "safer")?
> 
> On Mon, Oct 19, 2020 at 7:31 PM Siegfried Goeschl <
> siegfried.goeschl@gmail.com> wrote:
> 
>> Hi Daniel,
>> 
>> yes, I disabled them since I assume that they will be the default settings
>> 
>> Thanks in advance
>> 
>> Siegfried Goeschl
>> 
>>> On 11.10.2020, at 20:42, Daniel Dekany <da...@gmail.com> wrote:
>>> 
>>> I noticed that ?api and ?new are by default disabled in
>>> freemarker-generator. However, freemarker-generator is inherently unsafe,
>>> as it has tools.freemarker.objectConstructor, and
>> tools.freemarker.statics.
>>> For a command-line tool that's probably fine, but then above two
>>> configuration settings should be left on their convenient defaults as
>> well.
>>> 
>>> In general, allowing someone to specify arbitrary command line arguments
>>> to freemarker-generator CLI means that they can do pretty much anything
>> (as
>>> they can provide an arbitrary template with the -i option, then access
>> the
>>> tools). Again, I think such risk is expected from a command line tool,
>> but
>>> it's better if we are conscious about this.
>>> 
>>> --
>>> Best regards,
>>> Daniel Dekany
>> 
>> 
> 
> -- 
> Best regards,
> Daniel Dekany


Re: FreeMarker generator security related configuration defaults

Posted by Daniel Dekany <da...@gmail.com>.
Does that mean that you agree that we should leave them on the actual
FreeMarker 2.3.x defaults (?api enabled, ?new set to "safer")?

On Mon, Oct 19, 2020 at 7:31 PM Siegfried Goeschl <
siegfried.goeschl@gmail.com> wrote:

> Hi Daniel,
>
> yes, I disabled them since I assume that they will be the default settings
>
> Thanks in advance
>
> Siegfried Goeschl
>
> > On 11.10.2020, at 20:42, Daniel Dekany <da...@gmail.com> wrote:
> >
> > I noticed that ?api and ?new are by default disabled in
> > freemarker-generator. However, freemarker-generator is inherently unsafe,
> > as it has tools.freemarker.objectConstructor, and
> tools.freemarker.statics.
> > For a command-line tool that's probably fine, but then above two
> > configuration settings should be left on their convenient defaults as
> well.
> >
> > In general, allowing someone to specify arbitrary command line arguments
> > to freemarker-generator CLI means that they can do pretty much anything
> (as
> > they can provide an arbitrary template with the -i option, then access
> the
> > tools). Again, I think such risk is expected from a command line tool,
> but
> > it's better if we are conscious about this.
> >
> > --
> > Best regards,
> > Daniel Dekany
>
>

-- 
Best regards,
Daniel Dekany

Re: FreeMarker generator security related configuration defaults

Posted by Siegfried Goeschl <si...@gmail.com>.
Hi Daniel,

yes, I disabled them since I assume that they will be the default settings

Thanks in advance

Siegfried Goeschl

> On 11.10.2020, at 20:42, Daniel Dekany <da...@gmail.com> wrote:
> 
> I noticed that ?api and ?new are by default disabled in
> freemarker-generator. However, freemarker-generator is inherently unsafe,
> as it has tools.freemarker.objectConstructor, and tools.freemarker.statics.
> For a command-line tool that's probably fine, but then above two
> configuration settings should be left on their convenient defaults as well.
> 
> In general, allowing someone to specify arbitrary command line arguments
> to freemarker-generator CLI means that they can do pretty much anything (as
> they can provide an arbitrary template with the -i option, then access the
> tools). Again, I think such risk is expected from a command line tool, but
> it's better if we are conscious about this.
> 
> -- 
> Best regards,
> Daniel Dekany