about: remove blantly incorrect information about runc

It appears this document was drafted some time before runc gained
support for rootless containers (though it was written after I had
authored my original patch-set). None of the information contained in
that section was correct. Luckily dfba702 ("adding fork me on
github, page on environment metadata, and making tons of changes for
2.3!") removed some of the more blatant misinformation about runc, but
this section remained.

The main issues with this section are:

1. It misunderstands fundamentally how rootless containers work, and
   misrepresents their properties. There are limitations of rootless
   containers, but Singularity gets around those limitations by using
   setuid binaries (which are no better than a privileged daemon).

2. It ignores the existence of tools like umoci[1], which allow for the
   creation of a rootfs without privileges. While it is a "chroot-style"
   rootfs, I'm not sure I understand why this is a concern for a user
   (and the text resorted to the statement "it requires root" which is
   incorrect).

3. Previous versions made claims about security that were blatantly
   false. The security of rootless containers are provided directly by
   the kernel, and runc also supports tools such as seccomp (which are
   known to protect against kernel 0-days). Singularity provides its
   security through its own setuid code.

Signed-off-by: Aleksa Sarai <[email protected]>

pages/info/about.md

@@ -69,7 +69,7 @@ Singularity does not utilize a daemon process to manage the containers. While da
 
 Additionally, securing a root owned daemon process which is designed to manipulate the host's environment becomes tricky. In currently implemented models, it is possible to grant permissions to users to control the daemon, or not. There is no sense of ACL's or access of what users can and can not do.
 
-While there are some other container implementations that do not leverage a daemon, they lack other features necessary to be considered as reasonable user facing solution without having root access. For example, there has been a standing unimplemented patch to RunC (already daemon-less) which allows for root-less usage (no root). But, user contexts are not maintained, and it will only work with chroot directories (instead of an image) where files must be owned and manipulated by the root user!
+There are several container implementations that do not leverage a daemon. In addition, they do not require the installation of setuid binaries to operate. An example of this is the runc project which has merged a long-standing patch. In addition, runc is the de-facto implementation of the Open Container Initiative's runtime specification, making it compatible with a wide variety of other systems. With the use of tools such as umoci, a user can create a chroot enviornment without privileges, removing previous concerns about requiring root privileges to set up a container's rootfs.
 
 ## Use Cases