No command found to create a group or user, make sure the container is running as non-root in server-v3/.wappler/targets/Cloud Dev/web/Dockerfile
The issue noted, “No command found to create a group or user, make sure the container is running as non-root,” in your Dockerfile suggests that the Docker container might be configured to run as the root user. Running Docker containers as root poses security risks, especially if the container becomes compromised, as it could give attackers root access to the Docker host.
Importance of Non-root User in Docker Containers
Security Best Practices : Running containers as non-root reduces the risks of privilege escalation attacks. If an attacker compromises a container, they won’t have root access to the Docker host or other containers.
Principle of Least Privilege : This principle involves giving a user account or process the minimal level of access necessary to perform its tasks. This minimizes the potential impact of errors or security breaches.
How to Fix This Issue
To resolve this, you need to modify your Dockerfile to ensure that the container does not run as the root user. This typically involves creating a new user and group in the Dockerfile, then switching to this user. Here’s how you can do it:
Add a User and Group : You add commands to your Dockerfile to create a new user and group. Here’s an example:
Dockerfile
Copy code
FROM node:14
# Create a group and user
RUN groupadd -r myappgroup && useradd -r -g myappgroup myappuser
# Set the working directory
WORKDIR /app
# Copy application files
COPY . /app
# Switch to the new user
USER myappuser
# Continue with your Dockerfile setup
Switch to the Non-root User : After setting up the environment (like copying files, installing dependencies), switch to the non-root user using the USER command, specifying the username or UID.
Permissions : Ensure that any directories or files that the application needs at runtime are accessible to this non-root user. This might involve changing ownership or permissions of these files within the Dockerfile using the chown command.
By implementing these changes, you can enhance the security of your Docker containers and mitigate the risks associated with running containers as the root user. This is particularly crucial for production environments where the impact of security breaches can be significant.
This is actually not the best useful suggestion and also not true. It is not a problem to run the container under root because it is it is all contained. Running under different user causes only unnecessary settings and defining of more users with all different rights on folders etc, upload folders etc. So usually you will run in a lot of access denied errors.
In a container world the root user for the container is the only user and have access to the container only and not outside.
May I add something. I don’t see this as a Wappler issue. It is more the responsibility of the administrator for the infrastructure to resolve than for Wappler to accommodate. Docker is in many way as vulnerable as the administrator and their respective skill set.
I’m not knocking anyone here at all, so let me just clear that up.
BUT it is all too easy to deploy a technology you may not know that much about… This is by no means the fault of Wappler whatsoever. From past professional experience I know this too well from both sides of the fence.
I think the important thing to understand is Wappler can deploy incredibly complex applications. Using multiple libraries, and on-top of that independent Users adding in their own libraries and installing packages they know little to nothing about, on top of a technology they know little to nothing about (aside from the fact it works).
I know from when we decided to employ Docker we went through a steep learning curve starting with the very basics and working our way up until we had a grasp of most concepts.
During the time we administered our own servers we had over thirty years in hosting experience so had built up this knowledge, not only of the OS but the web stack we deployed.
We attended hundreds of hours of study and sat many an exam on the subjects…
But with Docker we knew we had a lot to learn, and had to learn it. So my point is some things Wappler can do need to be understood, to cut a long load of blurb short.
We have to educate ourselves on the stack we select. We have to do our homework. Docker security concepts are well documented even within Dockers own documentation. This should always have been the first stop in using Docker for everybody! Or if not security itself even the basics should be read and understood by the User who has chosen to deploy it.
Like I said I’m not having a pop nor being disrespectful to Keith or anyone else!! I too fall in to the same trap. And what makes it worse is I know I’m skipping a vital step and still occasionally jump too far ahead for my own good (luckily I have a business partner who forgives me, and a wife that understands I’m a bit special).
Basically, the point of running as non-root is to reduce the probability of container outbreak if a 0-day vulnerability is found. It’s the best practice to run as non-root.
Does it bother my current Wappler app is running as root? Not really, I didn’t even realize until I saw this thread.
If I were to run a hosting service for customers, would I care to make their apps run as non-root? Yes, absolutely.
Containers aren’t true virtual machines, the kernel is shared, subject to potential exploitation.
Docker even mentions it in their security documentation and link to rootless mode as a way to “run the Docker daemon and containers as a non-root user to mitigate potential vulnerabilities in the daemon and the container runtime.”
While I agree that it’s in our own interest to validate the tech stack we use. Knowing every potential vulnerability is nearly impossible. That’s why we have CASA, OWASP, MITRE CWEs, SAST, DAST, and a multitude of other security related items to help ensure we’re doing everything we can to provide secure systems for ourselves and our customers.
We can also help make the software we use better by ensuring vulnerabilities are addressed and that’s all this post was.
Whether the Wappler team thinks it’s worth addressing is up to them, but maybe, just maybe, it’s something easily fixable and one less worry for all of us. If not, then I’ll find another way to address the issue just for my projects.
Yep, and this is one of the major security areas mentioned in Docker’s Security docs.
There's already a non-root user in NodeJS' Docker image, ready-to-use.
I just think Wappler team is afraid of breaking stuff for existing users, due to potential permission issues (e.g. in file uploads, whose file ownership is root as the NodeJS app was running as root).
Its a bit like breaking down and knowing you should have a spare tyre and the AA arriving and asking where is your spare tyre. The root user container is similar to that scenario. And yes those services serve their purpose indeed, and for compliance purposes we have had to achieve very high standards ourselves in the past. So understand that side. But configuration issues by the User are not the fault of the software.
It is not a vulnerability in Wappler this is my point Keith. However I personally appreciate you bringing attention to the issue for those that do not understand. I'm sure your audit will bring up many other attack vectors that are not protected against by Wappler itself (which is very understandable as there are hundreds, if not thousands, dependant upon the scale and complexity of your audit).
Its a shame humans in the office can’t be audited! They are the greatest threat. Social Engineering is always the least protected against vector of attack. You do all that hard work and pay the money for a tight application and some mug in the office clicks a link to a kitten charity…
But I would argue that Wappler is using Docker as part of its underlying technology, so to help protect all of us, the team could make the improvements, and we wouldn’t need to worry about it just as we don’t typically have to worry about manually configuring docker-compose or any of the other software that Wappler bakes into the product.
To continue your analogy, it would be like the manufacturer of a car putting tires on it that they know have a defect and saying to its customers, “It’s not our problem; as a driver of a car, you should be informed enough to know about the defect and don’t drive over 25mph.”
There are, but many of them are not directly related to the technology that Wappler has integrated into the tool and are specific to the app(s) I’m building. But this one is shared across every Wappler project that uses Docker and I would prefer not to have to continually make updates if/when Wappler tries to modify the changes I make to files.
I'm so happy you and other members of this fine Community have a great sense of humour!
Ahhhh but to drive said car you need a license and for that you have to study and pass a test!
It is a rock and a hard place Keith. Damned if you do and damned if you don't. What fixes ones issue creates another for someone else so where does it end? Interesting topic for conversation and debate none the less, and am sure only good will come of it.
