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) < jenki...@nationwide.com> 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" <carljmo...@gmail.com> 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
