[omniORB] Securing a Name Service

[Duncan Grisby]

On Friday 29 June, John D. Heintz wrote:

> All we are looking for is to be able to provide read access (the
> corbaname: part of INS) to the general TCP connection and _some_
> controlled write access.  Any way of doing that write access is
> acceptable really.

If you can tolerate disabling outside connections while doing writes,
you could make a version of omniNames which reads a log file from a
previous run of the full version, but doesn't support the write
operations. Then to do a write, you kill the non-write version and
start the full version with a TCP wrappers set-up which prevents
outside access. Not exactly convenient, but it would work.

A better solution would be to derive a new interface from
CosNaming::NamingContext, with new versions of the write functions. A
simple version would be

interface AuthenticatedNamingContext : CosNaming::NamingContext
{
    void auth_bind (in Name n, in Object obj, in Cookie c)
      raises (NotFound, CannotProceed, InvalidName, AlreadyBound);

    void auth_rebind (in Name n, in Object obj, in Cookie c)
      raises (NotFound, CannotProceed, InvalidName);

    ...
};

where Cookie is some sort of hard-to-guess token. Then you kill the
implementations of the base CosNaming::NamingContext write operations,
and only allow the authenticated versions.

That would work OK if the clients with write access were in the same
local area network as the server, so the cookies couldn't be sniffed.
To make it properly secure for wide area use, you'd have to have some
sort of challenge-response or public key system.

Security is hard. :-(

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --