Re: [linux-security] Re: Configuration for binding to "secure"ports?

[Andrej Presern <andrejp luz fe uni-lj si>]

Olaf Kirch wrote:
> 
> On Fri, 29 May 1998 11:26:37 +0200, Pavel Kankovsky wrote:
> > Well, you could also modify bind() to pass the socket (using BSD-like
> > unix-domain socket magic) to a privileged "binder daemon" and let it
> > decide whether you are allowed to bind it to the given port--and do it
> > itself if you are.
> 
> I've toyed with this idea for some time... 2.1 offers a feature by
> which the kernel passes your uid/gid to the unix socket peer upon connect.
> This neatly solves the problem of authenticating anyone connecting to
> a unix socket.
> 
> While the new capabilities stuff definitely does it better for binding to
> a privileged port, other services (e.g. opening a modem port; writing
> utmp) might still benefit from this.

I appologize for the interruption but you are forgetting that Linux has
capability lists, which means that they are of limited length, because
you don't want to spend too much time and resources checking the
authority at a very fine grained level.

Your idea could be done quite easily however on a pure capabilities
based system, because the time that is spent checking the authority is a
constant O(0) or O(1) (depending on the problem and implementation).
Unfortunatelly, capability lists and (pure) capabilities are not the
same. They are actually two very different approaches, one of which is
in use today and the other is a better performer in all respects.

It has been proven that pure capability systems can solve some very
fundamental problems of information security, such as the 'confinement
problem' or the problem of separating the authority from the identity of
the object, while virtually no progress has been made with any of the
lists approaches (such as access control lists or capability lists)
within the last 20 years. It is so that while we can have mutually
suspicious objects working securely in the same environment (which is
required for credit card processing facilities for example), we rather
choose to have inefficient systems that have been stuffed on us 20 years
ago by large monopolist companies (that can't prevent that your data
isn't compromised by your younger sister (older brother if you choose
capability lists)).

UNIX has changed before and will change again, I hope.

Andrej

-- 
Andrej Presern, andrejp luz fe uni-lj si