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

[Jonathan S. Shapiro]

On Thu, 2005-10-27 at 11:50 +0200, Alfred M. Szmidt wrote:
>      1. Many (not all) elements of the POSIX API are not safe.
> 
> s/Many/Few/ and we agree, you do not even touch on the majority of
> POSIX love.

I think that we are using different measurements. I think you are
counting system calls, where as I am looking at key concepts. POSIX has
a very large number of perfectly safe system calls, but if the key
concepts are flawed then that doesn't matter very much.

>       open() -- assumes a universally shared, mutable store.
> 
> Nothing wrong with that.

Actually, this is HUGELY BAD.

The fundamental basis for security in any system is to start from an
initial condition where no communication is possible and then add
communication authority to the mix selectively and cautiously.

When you begin with a universally shared, mutable file system, you begin
with a universal communication path between arbitrary processes.

Any system that begins with this assumption is fatally flawed from a
security perspective.

>            -- requires use of a known-ineffective access control
>               mechanism
> 
> How is a bitmask ineffcient?

I didn't say "inefficient". I said "ineffective", as in "flatly does not
work". Please read the Harrison, Ruzzo, and Ullman paper, or review my
summary of it for Marcus a few days ago.

>            -- most applications have no need to access the file
>               system at all!
> 
> So don't call it.

Security and robustness doesn't happen when we rely on processes not to
do something. Security and robustness happen when we *ensure* that
things *cannot* happen.

The fact that all UNIX processes have authority to access the file
system as a "built in" authority violates least privilege.

>       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
> 
> You have not explained how socket() is screwed

Violation of least privilege, violation of initial confinement.

>    POSIX itself is simply too powerful and too dangerous to be allowed
>    unrestricted access to anything you want to protect.
> 
> Once again, you are putting POSIX over one and the same blanket,
> without showing why _ALL_ of POSIX is `too dangerous'.

Well, since I don't believe that _ALL_ of POSIX is too dangerous, that's
really not a problem.

The difficulty is that when you remove the parts of POSIX that ARE
dangerous, you are left with a bunch of system calls that you can't
actually use. read() and write(), for example, are not very helpful if
you don't have open().

>    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.
> 
> I disagree, look at OpenBSD.

OpenBSD security is a joke.

shap