Fix casing

Author: thespad

docs/misc/non-root.md

@@ -11,7 +11,7 @@ If you run one of our typical images in a standard Docker setup, the container i
 
 Some people take the position that a container running as root *at any point* is an unacceptable security risk. Those people typically misunderstand the attack surface of containers and where the risks actually lie. Having said that, there *are* some risks with having containers running as root; generally, a better solution to running every container as an unprivileged user is to run Docker itself rootless, but that's not always desirable. In these situations, being able to run a single container as a unprivileged user has its benefits.
 
-To give you some sense of a potential risk, let's take our SabNZBd image and let's imagine you've exposed it to the internet and for some reason allowed unauthenticated access. Now let's assume a user were to discover a Remote Code Execution vulnerability in SabNZBd, and were able to exploit it to get a shell in the container (not a simple task, but let's be generous). At this point you have a shell running as the unprivileged `abc` account, which heavily limits what you can do. There's no sudo/doas in the container so you'd likely need to chain a Privilege Escalation vulnerability (within the limited set of packages installed) to get root. Even at that point, with root access inside the container, you would then need a further Container Escape vulnerability in order to do anything meaningful to the host beyond simply deleting or modifying data in a mounted path (which you could do as a non-root user anyway). That said, some of our containers do require additional Capabilities to run, and these *could* be exploited by a user with root to affect the host in various ways.
+To give you some sense of a potential risk, let's take our SABnzbd image and let's imagine you've exposed it to the internet and for some reason allowed unauthenticated access. Now let's assume a user were to discover a Remote Code Execution vulnerability in SABnzbd, and were able to exploit it to get a shell in the container (not a simple task, but let's be generous). At this point you have a shell running as the unprivileged `abc` account, which heavily limits what you can do. There's no sudo/doas in the container so you'd likely need to chain a Privilege Escalation vulnerability (within the limited set of packages installed) to get root. Even at that point, with root access inside the container, you would then need a further Container Escape vulnerability in order to do anything meaningful to the host beyond simply deleting or modifying data in a mounted path (which you could do as a non-root user anyway). That said, some of our containers do require additional Capabilities to run, and these *could* be exploited by a user with root to affect the host in various ways.
 
 ## How?