Re: Supporting POSIX *users*

[Bas Wijnen]

On Thu, Oct 27, 2005 at 11:50:29AM +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.
> 
>       open() -- assumes a universally shared, mutable store.
> 
> Nothing wrong with that.

There is.  It is possible to protect private data from becoming shared by
malicious applications.  This is a good thing.  What you need for it is
confinement: in that case, a hostile application which can read your private
data cannot share it.  A universally shared mutable store makes confinement
impossible, and therefore giving private data to potentially hostile programs
dangerous.

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

ineffective.

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

Right, you want to secure your system by not making the wrong syscalls in your
code?  And why do you think a hostile application is going to live by that
rule?

>       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

Socket provides any process access to the entire network.  Since most
applications should only be able to access it through an intermedary, and this
cannot be enforced with socket (except in a jail with its own firewall, which
is too costly to be used for "most operations"), socket is screwed.

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

The problem is UID based authentication in general.  It is much too
coarse-grained to provide real security.

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

It seems you guys still don't understand each other.  When Jonathan says
POSIX, he means (or at least I think he does) "An operating system which
follows the POSIX specification to the letter".  That includes chroot, open,
UIDs, an not selectively maskable network, etc.  A system which does all of
that is very broken security-wise.  This doesn't mean that a system that does
parts of POSIX must be broken.  But a system which only does parts of it is
not a POSIX system.

>    The problems are *architecture* problems, not implementation
>    problems.
> 
> They are indeed implementation problems.

If you still think so after what I just wrote, could you please explain?

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

I think Jonathan will not consider OpenBSD defensible. ;-)

Example: If on OpenBSD you want to run a plugin from a website, can it prevent
the plugin to access the network?  Can it prevent it to communicate with a
running program which it knows has been compromised?

You may say "don't run untrusted plugins".  I can secure a computer that way:
just don't switch it on.

Running untrusted code is useful, and people will do it anyway, no matter what
the consequences are.  We can build an operating system which makes this
acceptable, instead of highly dangerous.

Let's do that.

Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature