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

[Alfred M\. Szmidt]

     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.

      open() -- assumes a universally shared, mutable store.

Nothing wrong with that.

             -- requires use of a known-ineffective access control
                mechanism

How is a bitmask ineffcient?

             -- most applications have no need to access the file
                system at all!

So don't call it.

      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

      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.

I don't think we disagree on that.

      [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.

I never was fond of setuid/getuid, and they aren't needed in the Hurd
since you can use auth to get the privs you need.

   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'.

   The problems are *architecture* problems, not implementation
   problems.

They are indeed implementation problems.

   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.