Re: [Exim] Exim and IBM DB2

On Saturday, December 15, 2001, at 12:54 AM, Greg A. Woods wrote:
> Perhaps you do not understand the fundamentals of Unix process security.

I think I have a pretty good grasp.

(1) It is simple to ensure that a process loads the binary shared object
that you intend.
(2) It is also just as simple to ensure that that object (file) does not
get modified as it is to ensure that the binary executable itself is not
modified.

If you do not know how to do these two things, then reading
documentation might help.

The Unix process security model has deficiencies as does dynamic
loading, but they are orthogonal and not impact each other if coded
correctly.

>> It's not like you are loading them from some site somewhere. You have
>> the module on disk owned by root. You know its inode. Load the module
>> with that inode, if it has changed, Exim very well could have been
>> changed too.
>
> There's ample discussion of this issue elsewhere -- suffice it to say
> that dynamic loading of code using known implementations must never mix
> with enhanced privileges if you want to keep your systems safe.

Yes there is ample discussion elsewhere. Suffice it to say your
argument is one sided.

Its not like you are loading code from just anywhere or at the request
of a user.

Exim is owned by root (or exim), the configuration file is owned by root
(or exim) and the shared modules to load would be owned by root (or
exim). If your code can be subverted to load the wrong module at a
users whim, then the code is improperly written. If you can change the
contents of those modules, then it follows that the contents of the
configuration file and the exim binary itself could be modified and you
have more serious problems [that are out of the scope of this
discussion].

>> Apache uses dynamically loadable modules and I am not familiar with any
>> exploitations that hinge on the fact that the modules were dynamically
>> loaded. PAM uses loadable modules.
>
> Perhaps instead of looking at existing implementations made out of
> convenience you should look instead at the research and learn why I've
> made these claims. Some of us are even concerned about running any
> dynamic-linked setuid binary let alone anything that can dynamically
> load new code at any time.

(1) They were not made out of convenience, but were simply designed with
convenience in mind.
(2) If your code can "dynamically load new code at any time" then you
designed it that way. If you write your code to dynamically load things
at specific times (immediately after configuration, for example) then
you shouldn't be concerned with it loading "at any time."
(3) Those concerned with running dynamically linked code can simply
compile statically. Those concerned with dynamically loaded modules can
simply _not use them_.

> Furthermore you've apparently completely ignored the more fundamental
> fact that dynamic loading is simply never necessary in this kind of
> scenario, especially when full source code is available.

Very little is _necessary_. That isn't the point. I have exim
"patched" up to do all sorts of things. I don't want to integrate those
changes into the source tree at all becuase the code is proprietary.

Exim could be coded in assembly -- C isn't _necessary_. Damn
convenient, don't you think? dynamically loadable modules for hooking
into different phases of exim processing (logging specifically) either
requires code modification or dynamically loadable module support. With
dynamically loadable modules, I don't have to patch every new version of
Exim as it is released -- only when the API changes.

I have code that would be happy to make available under BSD or LGPL to
handle clustered logging. The provide time synchronized logging of
clustered mail servers using a publish subscribe model. It allows
real-time graphing of inbound and outbound traffic without running any
additional code on the mail server itself as well as "on-the-fly"
addition of new mail servers in the cluster. The solution is scalable
and reliable. I write more than 5GB of exim logs per day.

The code is a dynamically loadable module for exim 3.22. It was in my
best interest to hack the dynamic loading into exim rather than the
logging. I would be happy to port the logging module to any flexible
module API that is implemented in future version of exim.

Again, if you think it is a security concern to use loadable modules,
then don't configure it to load any -- it couldn't be more simple.
The rest of this thread should probably happen off list as it is having
less and less to do with Exim. So, reply off list if you want to banter
further.

--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7