All,
I was proposing a video chat because I was concerned that we were not
understanding one another. I do think that we now understand each other and
the off list talk is not necessary. However, understanding is not necessarily
agreeing, lol.
As I see it we have really two options....
1) I blend my proposal with Carl's
2) Abandon running as a specific UID for generics sake.
Option 1 would look something like this:
RUN set -x \
useradd -g root -u 10001 tomee \
chown -R tomee:root /usr/local/tomee \
chmod -R g=u /usr/local/tomee
USER tomee
CMD ["catalina.sh", "run"]
This would allow:
The UID of 10001, something other than the defaults other containers may use.
No longer needing to alter the catalina.sh file, as the user would already be
there.
Not running as root as the default user.
Allowing the files to have group root permissions the same as the user as
outlined by Carl previously and the OpenShift instructions.
Option two would place being generic ahead of security. As I said before, that
is what tomcat does in their project.
No matter the direction, users should not be using our Dockerfiles directly.
Users should always build on what we provide to suit their needs.
I appreciate this discussion. Please, let me know what you think of the
blended option. I know we need to get something out fairly soon. Maybe we
just table this for a future decision and just release option2.
Thanks,
Rod.
On 11/25/19, 7:35 PM, "Carl Mosca" <[email protected]> wrote:
Hi Rod,
I am certainly willing to talk about this via Skype or similar.
I take no offense to a differing position on the desired used of running a
process as an arbitrary UID. I came along in a time when if you ran as
root or even did a sudo command you should have a good reason and be aware
of what you were doing so that you did not accidentally do an "rm -Rf" or
the like on some non-user directory of importance.
Having said that, I believe the idea of running any process as a user that
one cannot (hopefully) predict as a more secure approach may sound a bit
paranoid (I am guessing the above statement does as well to some). The
best explanation I have for the concern is italicized below from some of
Red Hat's docs on OpenShift:
*Running processes for applications as different user IDs means that if a
security vulnerability were ever discovered in the underlying container
runtime, and an application were able to break out of the container to the
host, they would not be able to interact with processes owned by other
users, or from other applications, in other projects.Use of assigned user
IDs is a part of the multi layer security strategy employed by OpenShift to
reduce risks were an application or the container runtime compromised.*
On the other hand, if containers are running on one or more hosts or k8s
clusters and they all have the same UID, there is certainly the potential
for additional harm should a vulnerability exist. If the UID happens to be
common (perhaps tomcat, apache, mysql, all run as 1001 in different
images/containers/versions by design for some), there is more risk
potential (that's probably a bit of a stretch and hopefully not actually
happening).
Let me know if you would like to talk. If you'd rather abandon the whole
notion of support for running as an arbitrary UID, I certainly understand
and respect that position. I won't be able to use the resulting images in
most of my current use cases but I get it and can adjust accordingly as
needed.
Regards,
Carl
On Mon, Nov 25, 2019 at 7:20 PM Jenkins, Rodney J (Rod) <
[email protected]> wrote:
> Carl,
>
> I also had issues posting to the group on Friday night/Saturday morning.
>
> I fear that we are talking past one another. I will try to be much
> clearer in my responses. If we cannot resolve this via email, I am
willing
> to host a Skype session to talk through. Anyone on the list would be
> welcome to join.
>
> We agree on the "why" running on anything other than root is a good idea.
> I think we are discussing more about the "how to" run on some other ID.
> What I did not understand is "why" you handle it the way you do.
>
> Also, I would like to pre-apologize if I am talking down to you or anyone.
>
> You say, "We don't know the UID until runtime." I am not sure why you
> would want to know what that UID is at all or ever. The /etc/passwd
> convers the username to the UID. The nice thing about Tomcat/TomEE, it
> runs as the user that calls it. As long as java is available, it will
> start.
>
> You propose that in order to create that specific user and start TomEE as
> that user, you do the following:
> 1) Alter the /etc/passwd file to have group write access
> 2) Altering catalina.sh to add the user to /etc/passwd
> 3) Setting the ownership of the /usr/local/tomee to UID:root
> 4) Setting permissions of all files and directories in /usr/local/tomee to
> g=u
> 5) "USER" 1001 in the Dockerfile
> 6) CMD ["catalina.sh", "run"] in the Dockerfile. This line will start
> TomEE as the UID set in #5
> 7) When Catalina.sh is run, it adds the user to the passwd file, then
> starts TomEE as UID 1001, in your case with the user tomee.
>
> I propose the following to create the user and start TomEE
> 1) useradd in the Dockerfile to create the user tomee in the /etc/passwd
> file
> 2) "USER tomee" in the Dockerfile
> 3) CMD ["catalina.sh", "run"] in the Dockerfile. This line will start
> TomEE as the UID set in #2
>
> To be clear, I have no pony in this race other than finding the best way.
> If I am wrong, I have learned something valuable!
>
> If you would like you can see my Dockerfiles in tomitribe/docker-tomee,
> grab them and run some tests. Some hosting providers have specific
> requirements for running as a user other than root. Maybe, that is why
> Tomcat has decided to sidestep the whole discussion and run as root out of
> the box and let the user sort it out. Maybe, we should do the same.
While
> it is a security issue, it becomes a default standard issue to try to fix.
>
> Have a nice day!!
> Rod.
>
>
>
>
>
>
>
> On 11/25/19, 4:01 PM, "Carl Mosca" <[email protected]> wrote:
>
>
> Hi Rod,
>
> I am seeing some of my messages bouncing back - perhaps they are too
> long
> so I apologize if this was already sent:
>
> I am not sure if you're asking "why" I think it's a good idea to run
> as an
> arbitrary UID or the "why" behind what's going on with doing so...I
> try to
> touch on all of it:
>
> We don't know the UID until runtime (but we do know that user will be
> in
> the root group). While I acknowledge that this seems clumsy at first,
> and
> I am far from a security expert, it does seem more secure to me if one
> cannot predict the runtime UID as Red Hat describes in the OCP docs.
> If
> one is always using the *same known* UID, I think the attack surface
> changes a bit.
>
> If there is a need or desire in any given container/application to
make
> that unknown UID be a particular user I see two options:
>
> One, we can change an already existing user which can be
> messy/hard/impossible depending file/directory ownership needs that
are
> required for some applications and order of installation operations.
> (When
> I say impossible I am thinking of a particular situation I bumped into
> which is admittedly a corner case and most likely not applicable
here.)
>
> The second option is just wait to create the user at runtime. Given
> the
> permission changes, we can modify /etc/passwd as described, which
> results
> in the creation of the user.
>
> In addition, other "chmod g=u" operations are what allows us to take
> ownership of other files/directories if/as needed at runtime.
>
> There are certainly situations where the username simply does not
> matter
> and the arbitrary UID in root group is used then there's no need to
> add a
> user.
>
> HTH,
> Carl
>
>
>
--
Carl J. Mosca
