You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Jean-Louis Monteiro <jl...@tomitribe.com> on 2022/03/13 07:34:28 UTC
Improve security defaults
Hi all,
Security is becoming more and more important these days. We see many more
attacks and we legitimely have to question ourselves regarding our defaults.
In essence, we rely on Tomcat which is our backbone and we have always
treated its defaults as being reasonably good as stated in this page
https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
When going live a couple of changes should be made to avoid discarding
information an hacker may use against us.
xpoweredBy giving the exact version of Tomcat for instance
The error valve attributes are set to false so it does not display Tomcat's
version and does not discard exceptions.
Should we somehow pre-configure TomEE to be a bit more secure?
The downside is that in development, with Arquillian or TomEE Maven plugin
we lose some useful information to debug and understand what's going on.
What do you think?
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
Re: Improve security defaults
Posted by David Blevins <da...@gmail.com>.
> On Mar 24, 2022, at 9:40 AM, Jenkins, Rodney J (Rod) <JE...@nationwide.com> wrote:
>
> David,
>
> I agree on everything you said. I may not have time on my plate. However, I am trying to encourage more involvement in the open source community. I think this would be a good project for someone new to the open source community. I will attempt to get this in to the next sprint or myself or someone else (if you are ok with it).
Any and all contribution from you or someone else is absolutely welcome!
Advice on new people: send them to the list and make them say "hello, I'm thinking of doing x" before they start working on something. New contributors often fall into the trap of not wanting to emerge from silence until they have something to deliver... only to get told they chose the wrong repo, didn't factor in something or should have taken another approach. All feedback they can get early.
Being chatty is good and in no way a burden or something to avoid :)
-David
>
> On 3/15/22, 2:49 PM, "David Blevins" <da...@gmail.com> wrote:
>
> Hey Rod,
>
> One of the ideas Richard mentioned is a script that can audit an install and flag up issues like showServerInfo="false".
>
> With your scripting skills, are you perhaps interested in working on something like that? We could include the script in the bin/ directory and people could run it to get say a multi-line output of pass/fail lines. Maybe something like the old System V startup output that has the left-aligned text with right-aligned green or red status.
>
> We could potentially have a page on the website like the Tomcat one and then go section by section and add checks to the audit script (one output line each check), then at the end of the script it can print the link to the doc.
>
> Just thinking out loud -- not sure what you have on your plate.
>
>
> -David
>
>> On Mar 14, 2022, at 7:07 AM, Jenkins, Rodney J (Rod) <JE...@nationwide.com> wrote:
>>
>> Hello all,
>>
>> One thing we could look at is the CIS Benchmarks for Tomcat found here: https://www.cisecurity.org/benchmark/apache_tomcat The benchmark is not perfect. For example, it does not mention adding:
>>
>> Valve className="org.apache.catalina.valves.ErrorReportValve" showServerInfo="false"/>
>>
>> This is something I think is important. It does recommend users do something similar by extracting the ServerInfo.properties from the catalina.jar, altering it, then repackaging it. As I stated above, it is not perfect, but many people are using this as a guide.
>>
>> We could add a page to the site pointing people to this link as well as bulleting some of the items we feel is most important. We should encourage all users to follow what makes sense for them.
>>
>> Thanks,
>> Rod.
>>
>>
>>
>>
>> On 3/13/22, 12:51 PM, "Zowalla, Richard" <ri...@hs-heilbronn.de> wrote:
>>
>> Nationwide Information Security Warning: This is an EXTERNAL email. Use CAUTION before clicking on links, opening attachments, or responding. (Sender: dev-return-28942-JENKIR14=nationwide.com@tomee.apache.org)
>>
>> ------------------------------------------------------------------------------
>>
>>
>> Thanks for brining up this important topic!
>>
>> Perhaps it would be a good idea to include a security walkthrough on
>> our web page (even if we only link to Tomcat) as well to cover this
>> (very) important topic. This could also include secure systemd
>> configuration, etc.
>>
>> In addition it might be an option to go the "mariadb" way (I am
>> thinking of 'mysql_secure_installation' [1]) and provide a shell / bash
>> (+ Windows) script, which we include in our distribution archives. If a
>> user execute the script, the default configurations are hardended.
>> However, we would need to "promote" it, so users get to know it.
>>
>> This would mitigate possible pain in our code base / tests / examples
>> or for developers working with or on TomEE applications (or on TomEE
>> itself).
>>
>> Wdyt?
>>
>> Gruß
>> Richard
>>
>>
>>
>> [1] https://mariadb.com/kb/en/mysql_secure_installation/
>>
>>
>> Am Sonntag, dem 13.03.2022 um 11:45 +0100 schrieb Jean-Louis Monteiro:
>>> Thanks David for the quick reply. There is probably a balance to
>>> find.
>>>
>>> I agree that the tradeoffs can hurt us more than the actual small
>>> settings
>>> to apply.
>>> They are pretty well documented and clear in the following page
>>> https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
>>>
>>>
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>>
>>>
>>> On Sun, Mar 13, 2022 at 9:58 AM David Blevins <dblevins@tomitribe.com
>>>>
>>> wrote:
>>>
>>>>> On Mar 12, 2022, at 11:34 PM, Jean-Louis Monteiro <
>>>> jlmonteiro@tomitribe.com> wrote:
>>>>> xpoweredBy giving the exact version of Tomcat for instance
>>>>> The error valve attributes are set to false so it does not
>>>>> display
>>>> Tomcat's
>>>>> version and does not discard exceptions.
>>>>>
>>>>> Should we somehow pre-configure TomEE to be a bit more secure?
>>>>> The downside is that in development, with Arquillian or TomEE
>>>>> Maven
>>>> plugin
>>>>> we lose some useful information to debug and understand what's
>>>>> going on.
>>>>
>>>> I think you raise a key point in that last sentence. If we do
>>>> things like
>>>> have TomEE eat stacktraces and fail silently by default, that
>>>> doesn't just
>>>> make it harder for people to write applications on TomEE, that also
>>>> makes
>>>> it harder for us to develop TomEE.
>>>>
>>>> I think that would likely translate into fewer people making it out
>>>> of the
>>>> development phase, which means fewer users, fewer contributors and
>>>> fewer
>>>> resources.
>>>>
>>>> We'd also have to sweep through all our test cases and examples and
>>>> ensure
>>>> that things like stacktraces are enabled, which would make tests
>>>> and
>>>> examples more complicated. It could also reinforce people using
>>>> the dev
>>>> settings in production if they're seeing them repeated in our 180+
>>>> examples. They'd still be in the position of having to read a doc
>>>> to undo
>>>> the settings before production.
>>>>
>>>> Not totally against, it just sounds very tricky.
>>>>
>>>> It's definitely a good conversation and there are likely specific
>>>> things
>>>> we can do that could be palatable but don't completely sacrifice
>>>> the dev
>>>> experience.
>>>>
>>>>
>>>>
>>>> -David
>>>>
>>>>
>>
>
>
Re: Re: Improve security defaults
Posted by "Jenkins, Rodney J (Rod)" <JE...@nationwide.com>.
David,
I agree on everything you said. I may not have time on my plate. However, I am trying to encourage more involvement in the open source community. I think this would be a good project for someone new to the open source community. I will attempt to get this in to the next sprint or myself or someone else (if you are ok with it).
Thanks,
Rod.
On 3/15/22, 2:49 PM, "David Blevins" <da...@gmail.com> wrote:
Hey Rod,
One of the ideas Richard mentioned is a script that can audit an install and flag up issues like showServerInfo="false".
With your scripting skills, are you perhaps interested in working on something like that? We could include the script in the bin/ directory and people could run it to get say a multi-line output of pass/fail lines. Maybe something like the old System V startup output that has the left-aligned text with right-aligned green or red status.
We could potentially have a page on the website like the Tomcat one and then go section by section and add checks to the audit script (one output line each check), then at the end of the script it can print the link to the doc.
Just thinking out loud -- not sure what you have on your plate.
-David
> On Mar 14, 2022, at 7:07 AM, Jenkins, Rodney J (Rod) <JE...@nationwide.com> wrote:
>
> Hello all,
>
> One thing we could look at is the CIS Benchmarks for Tomcat found here: https://www.cisecurity.org/benchmark/apache_tomcat The benchmark is not perfect. For example, it does not mention adding:
>
> Valve className="org.apache.catalina.valves.ErrorReportValve" showServerInfo="false"/>
>
> This is something I think is important. It does recommend users do something similar by extracting the ServerInfo.properties from the catalina.jar, altering it, then repackaging it. As I stated above, it is not perfect, but many people are using this as a guide.
>
> We could add a page to the site pointing people to this link as well as bulleting some of the items we feel is most important. We should encourage all users to follow what makes sense for them.
>
> Thanks,
> Rod.
>
>
>
>
> On 3/13/22, 12:51 PM, "Zowalla, Richard" <ri...@hs-heilbronn.de> wrote:
>
> Nationwide Information Security Warning: This is an EXTERNAL email. Use CAUTION before clicking on links, opening attachments, or responding. (Sender: dev-return-28942-JENKIR14=nationwide.com@tomee.apache.org)
>
> ------------------------------------------------------------------------------
>
>
> Thanks for brining up this important topic!
>
> Perhaps it would be a good idea to include a security walkthrough on
> our web page (even if we only link to Tomcat) as well to cover this
> (very) important topic. This could also include secure systemd
> configuration, etc.
>
> In addition it might be an option to go the "mariadb" way (I am
> thinking of 'mysql_secure_installation' [1]) and provide a shell / bash
> (+ Windows) script, which we include in our distribution archives. If a
> user execute the script, the default configurations are hardended.
> However, we would need to "promote" it, so users get to know it.
>
> This would mitigate possible pain in our code base / tests / examples
> or for developers working with or on TomEE applications (or on TomEE
> itself).
>
> Wdyt?
>
> Gruß
> Richard
>
>
>
> [1] https://mariadb.com/kb/en/mysql_secure_installation/
>
>
> Am Sonntag, dem 13.03.2022 um 11:45 +0100 schrieb Jean-Louis Monteiro:
>> Thanks David for the quick reply. There is probably a balance to
>> find.
>>
>> I agree that the tradeoffs can hurt us more than the actual small
>> settings
>> to apply.
>> They are pretty well documented and clear in the following page
>> https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
>>
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>>
>> On Sun, Mar 13, 2022 at 9:58 AM David Blevins <dblevins@tomitribe.com
>>>
>> wrote:
>>
>>>> On Mar 12, 2022, at 11:34 PM, Jean-Louis Monteiro <
>>> jlmonteiro@tomitribe.com> wrote:
>>>> xpoweredBy giving the exact version of Tomcat for instance
>>>> The error valve attributes are set to false so it does not
>>>> display
>>> Tomcat's
>>>> version and does not discard exceptions.
>>>>
>>>> Should we somehow pre-configure TomEE to be a bit more secure?
>>>> The downside is that in development, with Arquillian or TomEE
>>>> Maven
>>> plugin
>>>> we lose some useful information to debug and understand what's
>>>> going on.
>>>
>>> I think you raise a key point in that last sentence. If we do
>>> things like
>>> have TomEE eat stacktraces and fail silently by default, that
>>> doesn't just
>>> make it harder for people to write applications on TomEE, that also
>>> makes
>>> it harder for us to develop TomEE.
>>>
>>> I think that would likely translate into fewer people making it out
>>> of the
>>> development phase, which means fewer users, fewer contributors and
>>> fewer
>>> resources.
>>>
>>> We'd also have to sweep through all our test cases and examples and
>>> ensure
>>> that things like stacktraces are enabled, which would make tests
>>> and
>>> examples more complicated. It could also reinforce people using
>>> the dev
>>> settings in production if they're seeing them repeated in our 180+
>>> examples. They'd still be in the position of having to read a doc
>>> to undo
>>> the settings before production.
>>>
>>> Not totally against, it just sounds very tricky.
>>>
>>> It's definitely a good conversation and there are likely specific
>>> things
>>> we can do that could be palatable but don't completely sacrifice
>>> the dev
>>> experience.
>>>
>>>
>>>
>>> -David
>>>
>>>
>
Re: Improve security defaults
Posted by David Blevins <da...@gmail.com>.
Hey Rod,
One of the ideas Richard mentioned is a script that can audit an install and flag up issues like showServerInfo="false".
With your scripting skills, are you perhaps interested in working on something like that? We could include the script in the bin/ directory and people could run it to get say a multi-line output of pass/fail lines. Maybe something like the old System V startup output that has the left-aligned text with right-aligned green or red status.
We could potentially have a page on the website like the Tomcat one and then go section by section and add checks to the audit script (one output line each check), then at the end of the script it can print the link to the doc.
Just thinking out loud -- not sure what you have on your plate.
-David
> On Mar 14, 2022, at 7:07 AM, Jenkins, Rodney J (Rod) <JE...@nationwide.com> wrote:
>
> Hello all,
>
> One thing we could look at is the CIS Benchmarks for Tomcat found here: https://www.cisecurity.org/benchmark/apache_tomcat The benchmark is not perfect. For example, it does not mention adding:
>
> Valve className="org.apache.catalina.valves.ErrorReportValve" showServerInfo="false"/>
>
> This is something I think is important. It does recommend users do something similar by extracting the ServerInfo.properties from the catalina.jar, altering it, then repackaging it. As I stated above, it is not perfect, but many people are using this as a guide.
>
> We could add a page to the site pointing people to this link as well as bulleting some of the items we feel is most important. We should encourage all users to follow what makes sense for them.
>
> Thanks,
> Rod.
>
>
>
>
> On 3/13/22, 12:51 PM, "Zowalla, Richard" <ri...@hs-heilbronn.de> wrote:
>
> Nationwide Information Security Warning: This is an EXTERNAL email. Use CAUTION before clicking on links, opening attachments, or responding. (Sender: dev-return-28942-JENKIR14=nationwide.com@tomee.apache.org)
>
> ------------------------------------------------------------------------------
>
>
> Thanks for brining up this important topic!
>
> Perhaps it would be a good idea to include a security walkthrough on
> our web page (even if we only link to Tomcat) as well to cover this
> (very) important topic. This could also include secure systemd
> configuration, etc.
>
> In addition it might be an option to go the "mariadb" way (I am
> thinking of 'mysql_secure_installation' [1]) and provide a shell / bash
> (+ Windows) script, which we include in our distribution archives. If a
> user execute the script, the default configurations are hardended.
> However, we would need to "promote" it, so users get to know it.
>
> This would mitigate possible pain in our code base / tests / examples
> or for developers working with or on TomEE applications (or on TomEE
> itself).
>
> Wdyt?
>
> Gruß
> Richard
>
>
>
> [1] https://mariadb.com/kb/en/mysql_secure_installation/
>
>
> Am Sonntag, dem 13.03.2022 um 11:45 +0100 schrieb Jean-Louis Monteiro:
>> Thanks David for the quick reply. There is probably a balance to
>> find.
>>
>> I agree that the tradeoffs can hurt us more than the actual small
>> settings
>> to apply.
>> They are pretty well documented and clear in the following page
>> https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
>>
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>>
>> On Sun, Mar 13, 2022 at 9:58 AM David Blevins <dblevins@tomitribe.com
>>>
>> wrote:
>>
>>>> On Mar 12, 2022, at 11:34 PM, Jean-Louis Monteiro <
>>> jlmonteiro@tomitribe.com> wrote:
>>>> xpoweredBy giving the exact version of Tomcat for instance
>>>> The error valve attributes are set to false so it does not
>>>> display
>>> Tomcat's
>>>> version and does not discard exceptions.
>>>>
>>>> Should we somehow pre-configure TomEE to be a bit more secure?
>>>> The downside is that in development, with Arquillian or TomEE
>>>> Maven
>>> plugin
>>>> we lose some useful information to debug and understand what's
>>>> going on.
>>>
>>> I think you raise a key point in that last sentence. If we do
>>> things like
>>> have TomEE eat stacktraces and fail silently by default, that
>>> doesn't just
>>> make it harder for people to write applications on TomEE, that also
>>> makes
>>> it harder for us to develop TomEE.
>>>
>>> I think that would likely translate into fewer people making it out
>>> of the
>>> development phase, which means fewer users, fewer contributors and
>>> fewer
>>> resources.
>>>
>>> We'd also have to sweep through all our test cases and examples and
>>> ensure
>>> that things like stacktraces are enabled, which would make tests
>>> and
>>> examples more complicated. It could also reinforce people using
>>> the dev
>>> settings in production if they're seeing them repeated in our 180+
>>> examples. They'd still be in the position of having to read a doc
>>> to undo
>>> the settings before production.
>>>
>>> Not totally against, it just sounds very tricky.
>>>
>>> It's definitely a good conversation and there are likely specific
>>> things
>>> we can do that could be palatable but don't completely sacrifice
>>> the dev
>>> experience.
>>>
>>>
>>>
>>> -David
>>>
>>>
>
Re: Improve security defaults
Posted by "Jenkins, Rodney J (Rod)" <JE...@nationwide.com>.
Hello all,
One thing we could look at is the CIS Benchmarks for Tomcat found here: https://www.cisecurity.org/benchmark/apache_tomcat The benchmark is not perfect. For example, it does not mention adding:
Valve className="org.apache.catalina.valves.ErrorReportValve" showServerInfo="false"/>
This is something I think is important. It does recommend users do something similar by extracting the ServerInfo.properties from the catalina.jar, altering it, then repackaging it. As I stated above, it is not perfect, but many people are using this as a guide.
We could add a page to the site pointing people to this link as well as bulleting some of the items we feel is most important. We should encourage all users to follow what makes sense for them.
Thanks,
Rod.
On 3/13/22, 12:51 PM, "Zowalla, Richard" <ri...@hs-heilbronn.de> wrote:
Nationwide Information Security Warning: This is an EXTERNAL email. Use CAUTION before clicking on links, opening attachments, or responding. (Sender: dev-return-28942-JENKIR14=nationwide.com@tomee.apache.org)
------------------------------------------------------------------------------
Thanks for brining up this important topic!
Perhaps it would be a good idea to include a security walkthrough on
our web page (even if we only link to Tomcat) as well to cover this
(very) important topic. This could also include secure systemd
configuration, etc.
In addition it might be an option to go the "mariadb" way (I am
thinking of 'mysql_secure_installation' [1]) and provide a shell / bash
(+ Windows) script, which we include in our distribution archives. If a
user execute the script, the default configurations are hardended.
However, we would need to "promote" it, so users get to know it.
This would mitigate possible pain in our code base / tests / examples
or for developers working with or on TomEE applications (or on TomEE
itself).
Wdyt?
Gruß
Richard
[1] https://mariadb.com/kb/en/mysql_secure_installation/
Am Sonntag, dem 13.03.2022 um 11:45 +0100 schrieb Jean-Louis Monteiro:
> Thanks David for the quick reply. There is probably a balance to
> find.
>
> I agree that the tradeoffs can hurt us more than the actual small
> settings
> to apply.
> They are pretty well documented and clear in the following page
> https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Sun, Mar 13, 2022 at 9:58 AM David Blevins <dblevins@tomitribe.com
> >
> wrote:
>
> > > On Mar 12, 2022, at 11:34 PM, Jean-Louis Monteiro <
> > jlmonteiro@tomitribe.com> wrote:
> > > xpoweredBy giving the exact version of Tomcat for instance
> > > The error valve attributes are set to false so it does not
> > > display
> > Tomcat's
> > > version and does not discard exceptions.
> > >
> > > Should we somehow pre-configure TomEE to be a bit more secure?
> > > The downside is that in development, with Arquillian or TomEE
> > > Maven
> > plugin
> > > we lose some useful information to debug and understand what's
> > > going on.
> >
> > I think you raise a key point in that last sentence. If we do
> > things like
> > have TomEE eat stacktraces and fail silently by default, that
> > doesn't just
> > make it harder for people to write applications on TomEE, that also
> > makes
> > it harder for us to develop TomEE.
> >
> > I think that would likely translate into fewer people making it out
> > of the
> > development phase, which means fewer users, fewer contributors and
> > fewer
> > resources.
> >
> > We'd also have to sweep through all our test cases and examples and
> > ensure
> > that things like stacktraces are enabled, which would make tests
> > and
> > examples more complicated. It could also reinforce people using
> > the dev
> > settings in production if they're seeing them repeated in our 180+
> > examples. They'd still be in the position of having to read a doc
> > to undo
> > the settings before production.
> >
> > Not totally against, it just sounds very tricky.
> >
> > It's definitely a good conversation and there are likely specific
> > things
> > we can do that could be palatable but don't completely sacrifice
> > the dev
> > experience.
> >
> >
> >
> > -David
> >
> >
Re: Improve security defaults
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Hey Richard,
yes maybe we can add a script to help and users can run afterwards.
Probably a good compromise.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Sun, Mar 13, 2022 at 6:51 PM Zowalla, Richard <
richard.zowalla@hs-heilbronn.de> wrote:
> Thanks for brining up this important topic!
>
> Perhaps it would be a good idea to include a security walkthrough on
> our web page (even if we only link to Tomcat) as well to cover this
> (very) important topic. This could also include secure systemd
> configuration, etc.
>
> In addition it might be an option to go the "mariadb" way (I am
> thinking of 'mysql_secure_installation' [1]) and provide a shell / bash
> (+ Windows) script, which we include in our distribution archives. If a
> user execute the script, the default configurations are hardended.
> However, we would need to "promote" it, so users get to know it.
>
> This would mitigate possible pain in our code base / tests / examples
> or for developers working with or on TomEE applications (or on TomEE
> itself).
>
> Wdyt?
>
> Gruß
> Richard
>
>
>
> [1] https://mariadb.com/kb/en/mysql_secure_installation/
>
>
> Am Sonntag, dem 13.03.2022 um 11:45 +0100 schrieb Jean-Louis Monteiro:
> > Thanks David for the quick reply. There is probably a balance to
> > find.
> >
> > I agree that the tradeoffs can hurt us more than the actual small
> > settings
> > to apply.
> > They are pretty well documented and clear in the following page
> > https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Sun, Mar 13, 2022 at 9:58 AM David Blevins <dblevins@tomitribe.com
> > >
> > wrote:
> >
> > > > On Mar 12, 2022, at 11:34 PM, Jean-Louis Monteiro <
> > > jlmonteiro@tomitribe.com> wrote:
> > > > xpoweredBy giving the exact version of Tomcat for instance
> > > > The error valve attributes are set to false so it does not
> > > > display
> > > Tomcat's
> > > > version and does not discard exceptions.
> > > >
> > > > Should we somehow pre-configure TomEE to be a bit more secure?
> > > > The downside is that in development, with Arquillian or TomEE
> > > > Maven
> > > plugin
> > > > we lose some useful information to debug and understand what's
> > > > going on.
> > >
> > > I think you raise a key point in that last sentence. If we do
> > > things like
> > > have TomEE eat stacktraces and fail silently by default, that
> > > doesn't just
> > > make it harder for people to write applications on TomEE, that also
> > > makes
> > > it harder for us to develop TomEE.
> > >
> > > I think that would likely translate into fewer people making it out
> > > of the
> > > development phase, which means fewer users, fewer contributors and
> > > fewer
> > > resources.
> > >
> > > We'd also have to sweep through all our test cases and examples and
> > > ensure
> > > that things like stacktraces are enabled, which would make tests
> > > and
> > > examples more complicated. It could also reinforce people using
> > > the dev
> > > settings in production if they're seeing them repeated in our 180+
> > > examples. They'd still be in the position of having to read a doc
> > > to undo
> > > the settings before production.
> > >
> > > Not totally against, it just sounds very tricky.
> > >
> > > It's definitely a good conversation and there are likely specific
> > > things
> > > we can do that could be palatable but don't completely sacrifice
> > > the dev
> > > experience.
> > >
> > >
> > >
> > > -David
> > >
> > >
>
Re: Improve security defaults
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Thanks for brining up this important topic!
Perhaps it would be a good idea to include a security walkthrough on
our web page (even if we only link to Tomcat) as well to cover this
(very) important topic. This could also include secure systemd
configuration, etc.
In addition it might be an option to go the "mariadb" way (I am
thinking of 'mysql_secure_installation' [1]) and provide a shell / bash
(+ Windows) script, which we include in our distribution archives. If a
user execute the script, the default configurations are hardended.
However, we would need to "promote" it, so users get to know it.
This would mitigate possible pain in our code base / tests / examples
or for developers working with or on TomEE applications (or on TomEE
itself).
Wdyt?
Gruß
Richard
[1] https://mariadb.com/kb/en/mysql_secure_installation/
Am Sonntag, dem 13.03.2022 um 11:45 +0100 schrieb Jean-Louis Monteiro:
> Thanks David for the quick reply. There is probably a balance to
> find.
>
> I agree that the tradeoffs can hurt us more than the actual small
> settings
> to apply.
> They are pretty well documented and clear in the following page
> https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Sun, Mar 13, 2022 at 9:58 AM David Blevins <dblevins@tomitribe.com
> >
> wrote:
>
> > > On Mar 12, 2022, at 11:34 PM, Jean-Louis Monteiro <
> > jlmonteiro@tomitribe.com> wrote:
> > > xpoweredBy giving the exact version of Tomcat for instance
> > > The error valve attributes are set to false so it does not
> > > display
> > Tomcat's
> > > version and does not discard exceptions.
> > >
> > > Should we somehow pre-configure TomEE to be a bit more secure?
> > > The downside is that in development, with Arquillian or TomEE
> > > Maven
> > plugin
> > > we lose some useful information to debug and understand what's
> > > going on.
> >
> > I think you raise a key point in that last sentence. If we do
> > things like
> > have TomEE eat stacktraces and fail silently by default, that
> > doesn't just
> > make it harder for people to write applications on TomEE, that also
> > makes
> > it harder for us to develop TomEE.
> >
> > I think that would likely translate into fewer people making it out
> > of the
> > development phase, which means fewer users, fewer contributors and
> > fewer
> > resources.
> >
> > We'd also have to sweep through all our test cases and examples and
> > ensure
> > that things like stacktraces are enabled, which would make tests
> > and
> > examples more complicated. It could also reinforce people using
> > the dev
> > settings in production if they're seeing them repeated in our 180+
> > examples. They'd still be in the position of having to read a doc
> > to undo
> > the settings before production.
> >
> > Not totally against, it just sounds very tricky.
> >
> > It's definitely a good conversation and there are likely specific
> > things
> > we can do that could be palatable but don't completely sacrifice
> > the dev
> > experience.
> >
> >
> >
> > -David
> >
> >
Re: Improve security defaults
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Thanks David for the quick reply. There is probably a balance to find.
I agree that the tradeoffs can hurt us more than the actual small settings
to apply.
They are pretty well documented and clear in the following page
https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Sun, Mar 13, 2022 at 9:58 AM David Blevins <db...@tomitribe.com>
wrote:
> > On Mar 12, 2022, at 11:34 PM, Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
> >
> > xpoweredBy giving the exact version of Tomcat for instance
> > The error valve attributes are set to false so it does not display
> Tomcat's
> > version and does not discard exceptions.
> >
> > Should we somehow pre-configure TomEE to be a bit more secure?
> > The downside is that in development, with Arquillian or TomEE Maven
> plugin
> > we lose some useful information to debug and understand what's going on.
>
> I think you raise a key point in that last sentence. If we do things like
> have TomEE eat stacktraces and fail silently by default, that doesn't just
> make it harder for people to write applications on TomEE, that also makes
> it harder for us to develop TomEE.
>
> I think that would likely translate into fewer people making it out of the
> development phase, which means fewer users, fewer contributors and fewer
> resources.
>
> We'd also have to sweep through all our test cases and examples and ensure
> that things like stacktraces are enabled, which would make tests and
> examples more complicated. It could also reinforce people using the dev
> settings in production if they're seeing them repeated in our 180+
> examples. They'd still be in the position of having to read a doc to undo
> the settings before production.
>
> Not totally against, it just sounds very tricky.
>
> It's definitely a good conversation and there are likely specific things
> we can do that could be palatable but don't completely sacrifice the dev
> experience.
>
>
>
> -David
>
>
Re: Improve security defaults
Posted by David Blevins <db...@tomitribe.com>.
> On Mar 12, 2022, at 11:34 PM, Jean-Louis Monteiro <jl...@tomitribe.com> wrote:
>
> xpoweredBy giving the exact version of Tomcat for instance
> The error valve attributes are set to false so it does not display Tomcat's
> version and does not discard exceptions.
>
> Should we somehow pre-configure TomEE to be a bit more secure?
> The downside is that in development, with Arquillian or TomEE Maven plugin
> we lose some useful information to debug and understand what's going on.
I think you raise a key point in that last sentence. If we do things like have TomEE eat stacktraces and fail silently by default, that doesn't just make it harder for people to write applications on TomEE, that also makes it harder for us to develop TomEE.
I think that would likely translate into fewer people making it out of the development phase, which means fewer users, fewer contributors and fewer resources.
We'd also have to sweep through all our test cases and examples and ensure that things like stacktraces are enabled, which would make tests and examples more complicated. It could also reinforce people using the dev settings in production if they're seeing them repeated in our 180+ examples. They'd still be in the position of having to read a doc to undo the settings before production.
Not totally against, it just sounds very tricky.
It's definitely a good conversation and there are likely specific things we can do that could be palatable but don't completely sacrifice the dev experience.
-David