[cap-talk] Building a bridge: library API's and file descriptors?

Rob Meijer capibara at xs4all.nl
Wed Feb 4 02:15:14 EST 2009


On Wed, February 4, 2009 07:58, Steve Witham wrote:
>>  > 2009/2/2 Steve Witham <sw at tiac.net <mailto:sw at tiac.net>>
>>>
>>  >     Evolution seems to have crossed the gap between compound and
>>  >     single eyes in both directions.
>>
>>From: Matej Kosik <kosik at fiit.stuba.sk>
>>
>>What I have said I did not verify (bee eye being or not being able to
>>evolve into human eye. Please forget that).
>
> I didn't mean it was a bad analogy.  Just that the bee eye side of the
> analogy happens not to be true!  The idea of being stuck on an
> evolutionary local peak is a very important one.
>
> But if some people refuse to cross the valley,
> we may still be able to build them a bridge.

In order to build a bridge, one of the conceptually most simple fundation
seems to lay in library API's.

Most software relies heavily on libraries. Most library APIs DEMAND to
open their own files and sockets. This in turn makes that applications
build with these libraries REQUIRE a lot of ambient authority, so we can
not confine these applications to least privilege as a result of the
libraries we use.

We end up with applications that need to run with an abundance of
authority while being build with libraries we don't fully trust.

The solution seems simple, get the library vendors to extend their API to
accept file descriptors. File descriptors can be communicated between
unconfined and confined processes like capabilities, allowing applications
to confine their untrusted library usage if these libraries have an API
that accepts file descriptors instead of or next to paths, network
addresses and URL's.

Things like AppArmor and the netfilter owner-uid facility (combined with
setuid) are great tools to run processes in a confined least privilege
way.

File descriptor passing to these processes turns least privilege int least
authority. Changes to libraries seem trivial, but how do we convince
library vendors of the large merits of extending their API's in this
relatively trivial way?

Rob



More information about the cap-talk mailing list