Rod, I don't see value in creating the user in the root group in the image if one has a desire/need to run as an arbitrary UID as that same user.
I think I would leave out all of my suggested approach because as you said, folks can create their own images. We actually have some similar situations internally and we are renaming an already existing user to make things work. It's a bit odd but we're leverage that which we don't control. Thank you for the discussion and consideration, Carl On Tue, Nov 26, 2019 at 10:50 AM Jenkins, Rodney J (Rod) < jenki...@nationwide.com> wrote: > 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" <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
