You could build a POSIX system on seL4, but it won't take advantage of the capabilities that seL4 provides, because capabilities are absent from the POSIX APIs.

You could build a POSIX system on seL4, but it won't take advantage of the capabilities that seL4 provides, because capabilities are absent from the POSIX APIs. Consider for example: FILE *fopen(const char *filename, const char *mode) There's nothing in this function signature which specifies a capability to perform the open. Instead, there's an access control list somewhere else, where permission is looked up as to whether the file can be accessed by the current uid or whatever. Rule #1 of capabilities is: Don't separate designation from authority. Rather than a filename, a capability based API for opening files should take a capability argument instead of a filename, which both designates which file to open and provides the authority to open it, without attempting to look up that authority elsewhere. And notably, this capability cannot be forged - it can't be generated from a string containing the name of the file. So the first step to making a POSIX on seL4 is to get rid of the POSIX API and replace it with a better API based on capabilities. Then of course, it is no longer POSIX. The reason to use capabilities rather than ACLs is that ACLs are vulnerable to confused deputy attacks. Linux namespaces have numerous security vulnerabilities that could be avoided with capabilities. Also note that POSIX "capabilities" are not proper capabilities in the sense they're used in capability based security (as in seL4).