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

[Tobi Oetiker]

Hi Sebastian,

Today Sebastian Harl wrote:

[...]
> When signing the communication, other users on the network could still
> read along the communication and, thus, get all information (e.g. data
> that's about to be added to some RRD file). So, people should be aware
> that this protects against unauthorized _write_ actions but basically
> does not protect against _read_ "access". When Florian provided his set
> of patches to allow fetching data from the daemon, Tobi requested that
> this kind of access ought to be protected.

my point was not 'particularly' about reads, only that I was
repeating my concern about the unauthenticated access and that the
more the cacheds abilities grew the more concerned I was about it.

I am very happy with Kevins patch, since it significantly raises
the level of effort required to penetrate the system.

There is nothing in the patch, preventing a future addition of
a STARTTLS command with all SSL goodness (and complexity).

So I am not quite sure what you are aiming at at the moment. Does
this patch in any way hinder the future addition of encryption ?


> On Wed, Apr 29, 2009 at 10:29:31PM +0200, Tobias Oetiker wrote:
> > Today kevin brintnall wrote:
> > > > Would it make sense to have a secret and a user name, so that the
> > > > communication would look like this?
> > >
> > > A user name may reduce the number of SHA1 comparisons (since we'll be able
> > > to terminate the search earlier).  Currently we don't have any other
> > > access restrictions or logging that would benefit from a user name.  Do
> > > you foresee a need for any user-based authorization mechanisms?
> > >
> > > Do you foresee a need for a large number of secrets?
> >
> > not at the moment, but florian has mentioned an idea for different
> > levels of rights.
> >
> > but I guess if this comes to pass the protocol could be enhanced by
> > a second authentication key word which caters for authentication
> > including a user name ...
> >
> > for my use case, the present implementation is all I need.
>
> This would also require another user / password database (in addition to
> the auth_file that's required by the current implementation) since it's
> not possible to enhance the auth_file in a backward-compatible way. So,
> why not do it right from the beginning and avoid bloating the implemen-
> tation and confusing users by having multiple different security
> concepts?

I think this touches on a major struggle in system design, since we
are all experienced people with vivid imagination for things
possible, we are always in danger to suffer from second system
syndrom. For me it often comes to a point where I never leave the
design phase ...

In OSS projects the root of the evil in my opinnion is, that we do
not have a outside (paying) customer who defines the problem that
our tool should solve. Hence featers grow left and right and it is
hard to keep the whole system at least on some level of
consistancy.

My current 'solution' is to at issues from my point personal point
of view, which features do I need in my environment this helps me
to keep linked with my reality, and resources available.

If there is an entity who requires, and is willing to finance the
implementation of SSL support (or users, or authentication levels)
I am sure we will find a way to integrate this sensibly and also
someone willing to write the code ...

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900