Hi Rod, I believe we're on the same page with the desire to run as a non-root user. Technically I guess the arbitrary UID could be root but that flies in the face of its purpose which is to prevent predicting the UID to reduce the possibility of exploiting a vulnerability should one exist. When I started with Docker, this was one of the questions that kept me up at night: what if this thing that's running as root has a vulnerability or the thing that the thing runs in has one. :) . So I may be a bit predisposed to looking for any additional security I can get "by default" in a running container.
If we are running in OCP, the UID and root group are taken care of. When we test in Docker locally (which seems to be more of the exception these days) we pick a high UID out of habit along with the root group to simulate what will happen in OCP. FWIW, I respectfully disagree with your Docker folks; I think it's never better to leave it as root. I was a bit surprised that this was the default Docker way and I imagine other container standards which are more secure becoming increasingly popular. I do believe this particular community is responsive, polite and professional and you will arrive at the right choice for the time. I am certainly not offended if you/the community decide that something that looks more like everything is preferred for whatever reason. Regards Carl On Tue, Nov 26, 2019 at 1:50 PM Jenkins, Rodney J (Rod) < jenki...@nationwide.com> wrote: > Carl, > > I apologize for thinking you did not understand the issue of setting root > and the primary group. I missed how you were setting that in your example. > > I viewed "arbitrary UID" as an id other than root. Are you defining it as > a UID set by the environment at execution? My entire premise was just to > avoid the running as root user. That may be a bad premise to start with. > > I have spoken with some of our internal Docker folks, their response was " > For the generic open source image, it is probably better to leave it as > root." > > Being newer to the group, I am not sure how we make final decisions. > > Thank you, > Rod. > > > On 11/26/19, 12:01 PM, "Carl Mosca" <carljmo...@gmail.com> wrote: > > > Rod, > > Thank you. I do understand the use of the root group. My statement > included the assumption that one wanted to run as an arbitrary UID > with the > same already created username. > > I am not certain it was sent, but one of the points I think I tried to > make > early on was the need/desire to run as a particular user which is > running > as an arbitrary UID. > > The scenario I believe you're describing is creating a user with some > UID > and in the root group and then not utilizing the user at runtime and > instead running as an arbitrary UID. > > I thought folks might find it odd that the tomee user exists but it > would > not be utilized but as you said, you need to hear from others. > > Regards, > Carl > > On Tue, Nov 26, 2019 at 12:00 PM Jenkins, Rodney J (Rod) < > jenki...@nationwide.com> wrote: > > > Carl, > > > > The reason you add the user with the primary group is that all files > > created by that user would then have the group of root. If you did > not > > include that, then the new files created would have a user of tomee > and the > > root group would not have permissions on those files. I found this > when I > > attempted what OpenShift recommended. I started TomEE, got to the > command > > line and saw files created at run time without the root group. > > > > " It's a bit odd but we're leverage that which we don't control." > Agreed, > > we all do. > > > > I would like to have input from the rest of the group. > > > > Thanks, > > Rod. > > > > On 11/26/19, 10:50 AM, "Carl Mosca" <carljmo...@gmail.com> wrote: > > > > > > 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 > > > > > > > > -- > Carl J. Mosca > > > -- Carl J. Mosca -- Regards, Carl
