Password sync plugin, and questions about plugin criticality

[Roland Dowdeswell]

On 1151337186 seconds since the Beginning of the UNIX epoch
Ken Hornstein wrote:
>

>>We have all seen the ... fun of library versioning problems, 32/64
>>bit lib issues, etc. that are caused when you decide to go with a
>>plugin architecture rather than an IPC architecture.  Is there a
>>compelling reason in this case to not avoid these issues?

>There's already a plugin architecture in MIT Kerberos for extensions.
>This was the direction they decided to go in; I'm just along for the
>ride :-)  (Although I see no reason why you couldn't create a simple
>"shim" plugin that talked via IPC to the complicated bits).

I'm not specifically complaining about your actions but rather the
choice to go with a plugin system to start with.  It encourages
the wrong thing.

It's never too late to consider architectural changes.

Well structured security software is designed to run each component
at the lowest level of privilege possible.  A good example would
be Postfix which is comprised of many processes each with a specific
function run with the rights to perform said function.  Often in
a chroot(2) jail.

A well designed IPC mechanism would allow the flexibility to run
code at a lower level of privilege.  And it would be a step in the
right direction rather than the wrong direction.

If one has a plugin that performs token based authentication, it
seems unlikely to me that code would need to, say, read the key
for krbtgt/REALM at REALM.

Or if one decides to implement new database backends as an IPC
mechanism rather than as a plugin framework then one would be free
to put restrictions on kadmind to have a write-only interface.
This is a design goal of the current kadmind---but one that is only
enforced before kadmind is remotely compromised.  With kadmind
running as a non-root user in a chroot(2)-jail communicating with
the database backend via IPC, one could enforce this constraint
even in the face of a rogue kadmind.

Many if not most plugins have no need to run in the highest security
context available in the networked environment.  And if they have
no need to run at that maximal privilege then they should not.

I think that it is instructive to note that Postfix, e.g. has had
a very good security record largely because of its well thought
out design and attention to detail.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/