Thank you Jon - that reminder about open communication is much appreciated.
Carl On Tue, Nov 26, 2019 at 6:48 AM Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > 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 <carljmo...@gmail.com> 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) < > > 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 > > > -- Carl J. Mosca
