Thank you both for the excellent conversation on this topic, and for the visibility for everyone else on the list.
I would encourage you to keep going - it doesn't sound like you're too far apart. In terms of communication, the preference is to not have off-list conversations, but if you do, we'd like you to follow up on the list after. The reason for this if a decision is made on the approach, we'd want to ensure the community has visibility of that and is able to participate in the wider conversation. If a PR shows up, the committer merging it will need the background and understand the change prior to merging it. I'm just looking at Carl's PR: https://github.com/tomitribe/docker-tomee/pull/33/files. I think I possibly have some misunderstandings, so I'm going to try it with Docker on my desktop and on OpenShift. I might have some questions. :-) Thanks for the great thread and the open communication! Jon On Tue, Nov 26, 2019 at 1:34 AM 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 >
