dynamic /bin /sbin

[Robert Watson]

On Fri, 25 Jul 2003, Bosko Milekic wrote:

>   Personally, I myself prefer the so-called "IPC" approach to doing
>   nsswitch.  Namely, a daemon which is itself possibly
>   dynamically-linked and which may do caching, and where the libc code
>   talks to the daemon and has a local 'fallback' method.
> 
>   FWIW, some guys at RSU (the russian RSU, Rostov State University)
>   claim to have some daemon code which puts us on the path towards
>   exactly the above-described model.  This model does not require a
>   dynamically-linked root.  I think that OS X does something along those
>   lines, too.

You are correct that, in general, OS X isolates services relating to
authentication and directory services in separate tasks (processes) and
uses IPC to communicate with them.  However, OS X also is entirely
dynamically linked, with (I believe) the exception of init.  The
authentication and authorization services in OS X are moving fairly
rapidly away from being entirely centered around NetInfo to being centered
around a set of well-defined Service APIs exposed via Mach IPC.  There
seem to be a few layers to addressing these problems correctly: define
APIs that provide sufficient generality to do what you want, then
determine the place the code executes by virtue of your more general
system architecture and requirements.  A reasonably written API on the
front-end should support whatever implementations you need on the back.
And ideally, you shouldn't have to rewrite your applications when you
change your mind.

In a system oriented more around light-weight IPC, isolating those
components makes a lot of sense to me.  However, one of the big problems I
keep bumping into in OS X, from a security perspective, is a lack of a
trustworthy IPC namespace -- this will likely keep biting them in various
forms.  Given the discussion here of improving the IPC infrastructure for
a more message-passing oriented system, I hope the benefits of a
hierarchal and security-aware IPC namespace won't be lost.  :-)

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at xxxxxxxxxxxxxxxxx      Network Associates Laboratories