Consider providing a "hardened" tomcat

[sellersj]

Please considering providing a docker image that would be ready for production use.

Guides
https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html
https://www.owasp.org/index.php/Securing_tomcat

Also related to using the native library #7

[schlomo]

See also the switch to run tomcat as root in 6f1c628 and the discussion in #3

[yosifkit]

Would the tomee image be similar to what you are looking for? (docker-library/official-images#889, via: https://github.com/tomitribe/docker-tomee)

[schlomo]

EE stands for Enterprise Edition IIRC which mostly means that a lot more stuff is bundled into it.

My concern is more related to operational security and part of the bigger "whose docker images can we trust" question.

[macropin]

Until these security issues are addressed we can't reasonably put this container into production unaltered. And if we can't use the official container in production, then what is the point really? There needs to be better oversight on the security issues. #6 should never have been merged.

[xenoterracide]

I am currently copying the dockerfile because of this, I don't know that I would call not running a daemon as root "hardening", when I think hardened I tend to think of tools like SELinux, this is just a security vulnerability.

[gravis]

Any news on this? It's a serious concern I think, not only the container needs to run as root, but there's no user switch to run tomcat, so it runs as root too.
I don't this is acceptable for an official image.
Thanks

[yosifkit]

With user namespaces this is less of an issue than it has been in the past. You can map "container root" to be any specific user id on your docker host (see blog and docs). That said, we are considering adding similar improvements as docker-library/rabbitmq#60 to make docker run -d --user 1000 tomcat work.

[tianon]

(and things like SELinux, AppArmor, and seccomp filtering happen at the Docker level when you run the container through various runtime flags, so they don't apply directly at the image level)

[macropin]

@yosifkit I noticed the same was merged for MariaDB (potentially breaking docker-entrypoint-initdb.d scripts that depend on root.)

But why do it this way? Are there calls for arbitrary user support (I don't have a need for it)? Don't we just want plug-and-play containers that are secure by default?

[tubbynl]

most official images run on non-root users; it's a bit weird that this official image by default doesn't

i've extended the base image according to some of the OWASP remarks:

FROM library/tomcat:8.0.36-jre8-alpine

RUN rm -R $CATALINA_HOME/webapps/* && \ 
    addgroup -g 900 tomcat && adduser -h $CATALINA_HOME -u 900 -G tomcat -s /bin/bash -D tomcat && \
    chown -R tomcat:tomcat $CATALINA_HOME && \
    chmod 400 $CATALINA_HOME/conf/* && \
    chmod -R 300 $CATALINA_HOME/logs && \
    chmod -R 600 $CATALINA_HOME/temp

ADD *.war $CATALINA_HOME/webapps/ROOT.war

USER tomcat

[iammyr]

@tubbynl you also need to add the following:

RUN chmod -R 550 $CATALINA_HOME
RUN chmod -R 550 $CATALINA_HOME/webapps/

and then chown to give root:tomcat ownership on the tomcat folder recursively + give tomcat:tomcat ownership on the /conf /logs and /work subfolders recursively.

Otherwise, an eventually vulnerable application running on tomcat may be able to run "rm -rf" on the webapps folder or on other tomcat folders. For more accurate details and examples, see my pull request.

[gravis]

Or even worse: modifying some files. It will take some time before someone notices that the index.jsp file is now redirecting users to some porn site...

[yosifkit]

The reason for official images to not run as root is based on the purpose of the image. Images that are a service like mysql and postgres run as a specific user since we know ports and file system usage ahead of time. Images that are for running a users code like django, golang, python, node, tomcat, etc, run as root since users often mount their own code in and we cannot guarantee that user 999 in the container, for example, would have access to whatever they mount. In order to provide "plug-and-play" images, we run as root. A user is free to do their own image FROM tomcat that sets a different user and adds correct permissions for their files; I had also mentioned that we contemplated making an entrypoint that chowns and drops to a non-root user, but that messes with users' bind-mounted files.