Re: Supporting POSIX *users* (was: Re: Does supporting POSIX applications require ACLs?)

[Jonathan S. Shapiro]

On Wed, 2005-10-26 at 13:42 +0200, Alfred M. Szmidt wrote:
> Let me elaborate instead, since Jonathan has comprehension
> difficulties
> 
>    >    I don't see a way to start with POSIX and then improve it from
>    >    there.  POSIX has inherent insecurities built in.  There are
>    >    not many, but [...]
>    > 
>    > So simply ignore those insecuritites.
> 
>    Oh yes. That has worked *so* well for Microsoft.
> 
> But not _adding_ those insecuritites, 90% of POSIX is damn good, and
> has nothing to do with security, and is merly a API for writting
> portable programs.  The remaining 10% have to do with some bits of
> security, uid's and file permissions.  These bits can be _ignored_ and
> something different implemented on instead.  Just like not
> implementing chroot(), and using something different that is secure.
> 
> But you knew that and had to start a flame instead, and make absurd
> claims that all of POSIX is inherently insecure, when in reality it
> the majority of POSIX is totally irrelevant to implementing a secure
> operating system.

Good. Let us take this apart and look at it. First, let me state what I
*actually* claim:

  1. Many (not all) elements of the POSIX API are not safe.

  2. Some of the problems are obscure, and could be "left out" without
     damaging many applications. Unfortunately, many are absolutely
     central to the definition of POSIX, and these cannot be fixed
     compatibly -- or in cases where they *can* be fixed, the fix
     involves too much overhead to be effective as a default behavior.

  3. In most cases, the problems are not in the APIs per se, but
     in the assumptions *behind* the APIs.

     As we have established in a previous thread, programs do not
     rely only on interfaces. They rely on behavior. The real problems
     in POSIX lie in the required behavior.

Here are some examples of system calls that I do not believe can be
fixed, or cannot be fixed cost-effectively:

   open() -- assumes a universally shared, mutable store.
          -- requires use of a known-ineffective access control
             mechanism
          -- most applications have no need to access the file
             system at all!

   socket() -- the entire network subsystem design is screwed,
             but the main issue is that most applications should
             not be able to access the network except through an
             intermediary

   chroot() -- intended to be part of a basis for secure subsystems.
             partially effective (if extended) for things that can be
             statically preconfigured, but utterly useless for highly
             dynamic situations such as browsers, which is where we
             really need the help. A good dynamic solution would make
             chroot() unnecessary.

   [gs]etuid -- an entire mechanism designed to provide privilege
             escalation. Privilege escalation is an absolute "no no"
             in a secure system design.
             -- as a practical matter, known to be a critical source
                of real-world problems, and also known to be very
                prone to maintenance errors.

In each case, I can see how to build the API safely for the majority of
uses, and probably well enough to "get away with it" for purposes of
normal application support. But doing this is not the same as doing
POSIX. It's a compatibility layer.

POSIX itself is simply too powerful and too dangerous to be allowed
unrestricted access to anything you want to protect.

The problems are *architecture* problems, not implementation problems.
It is not a matter of "not adding insecurities". You can be POSIX, or
you can be secure, but you need to pick one.

Finally, I disagree with the statement "in reality [] the majority of
POSIX is totally irrelevant to implementing a secure operating system".
This statement is utterly wrong and extremely dangerous. Security is not
something that you can add on successfully after the fact. We have 45
years of hard experience in system after system after system to
demonstrate this -- including POSIX systems. If you want to succeed in
building a defensible system, considerations of security must be
examined in every single operating system feature as it is designed.

Perhaps Alfred has a hidden miracle that will solve this, but he has not
disclosed it.


shap