[rrd-developers] [PATCH] rrdcached server-side authentication

[Florian Forster]

Hi,

On Tue, May 05, 2009 at 08:58:37AM -0500, kevin brintnall wrote:
> Until we have per-command authorization, I'm thinking we should add a
> 3rd type of socket that requires authentication for everything.  This
> type would be appropriate for any untrusted connections.  This would
> let us maintain local read-only users while still heavily restricting
> external use.

I have to admit I don't think this good socket/bad socket architecture
will get us anywhere. Wouldn't it be easier to implement per-command
permissions for each socket now instead of creating a legacy we won't
lose for some time? I won't have enough time myself to take a look at it
before Monday, May 11th, but I'm willing to work in that direction after
that.

I know Tobi wants to release 1.4 soon but I think we shouldn't let this
rush us into premature designs that will be a problem to work with in
later version.

> Once we have per-command authorization, we won't need to make the
> distinction at the socket level.

In my above statement I assume you want to preserve backwards
compatibility, of course.

> > -> release 1.4
> > 
> > * add SSL support to guard against 3rd parties doing funney things
> >   on the network level.
> > 
> > * add configurable per-operation/per-file privileges
> > 
> > * add support for certificate based authentication

I really don't feel comfortable with half-implemented security in a
hurry just to get a release out. My suggestion is to add per-command
permissions for each socket, so admins can fine-tune what is possible
over the network and plan authentication for 1.5 (i. e. leave it out of
1.4). We then have all the time we need to implement really *secure*
measures that really would allow one to use the daemon via a WAN. Using
unencrypted authentication over a WAN (without further security
measures, as Tobi has hinted at earlier) is a *major* security risk and
belongs into the nineteen nineties.

I know I'm beginning to sound like a stuck LP, but if we integrate
authentication without encryption and without integrity check of the
transmitted data some people will think that the daemon is secure. Some
people will use it over the internet because there's a password, right?
This, in my opinion, is the real threat. As long as people are aware
that there is no security built-in whats-o-ever, they can take
appropriate counter measures. That people ask about authentication shows
that they are sensitive about it and probably will set up a VLAN, VPN or
whatnot. If you tell them that there is “authentication” some will
mistake this for “security” – which of course it is not.

If we implement those per-command configuration possibilities, admins
will have something to work with. If we add *real* security later, they
will surely welcome that, but for the time being they know that they
cannot use the daemon over the internet.

So please don't rush – we have no market shares to lose or anything.
Let's do it right from the beginning and avoid creating a nasty legacy.

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090506/486b3f75/attachment.bin