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

[Sebastian Harl]

Hi Tobi,

On Sun, May 03, 2009 at 02:27:44PM +0200, Tobi Oetiker wrote:
> 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'm pretty sure this has already been said before: Setting up authenti-
cation is something the local administrator _has_ to take care of him-
self, no matter if it's built in or available as some general solution.
So, if unauthenticated access is possible, it's the fault of that sys
admin but not RRDCacheD's fault. I'm not saying that built-in authen-
tication should not be made available but it should be done right. And
in my (I guess not so humble) opinion, authentication without encryption
(and what's even worse, even without any "authentication" of the data,
i.e. signed data) is something that's definitely not done right.

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

So, are you saying that your goal was to provide some "moderate level"
of security? Do you accept that there are known issues with the current
implementation? In that case, this should be documented - however, I
cannot image you'd want to document known security related issues in the
manpages.

Before, no authentication was built in at all, so users had to take care
of that themselves. Now, users might get the impression that secure
authentication can be handled by the daemon and do not take care of any
additional precautions. So, in that case, the efforts required to
penetrate the system are actually decreased. And since you were talking
about users that use it "irresponsible and wrongly" before I don't think
I'm exaggerating ...

I might just be that I do not understand what kind of problem you're
trying to solve. Whatever that is, if you really think that the current
solution is a way to go, that problem should be documented so people
will know what kind of problems have _not_ been solved by the daemon
itself and should be taken care of by additional precautions - just the
way it was originally meant (and documented) for everything related to
authentication as well.

> 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 ?

No, of course, it does not. I'm mostly just saying that authentication
without encryption is incomplete and provides a false sense of security.
I think that the current implementation plus the ability to sign data
might be a reasonable first step.

What this patch / the current implementation imho _does_ hinder though
is the ability to provide a reasonable more powerful way to manage
permissions (see below).

> > 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 ...

I agree that imagination might cause people to over-design stuff.
However, I do not see how the current situation is related to the second
system syndrome. We've got two suggestions where one is much more power-
ful than the other but, I suppose, does not add a lot of complexity. In
contrast, if we later decide that the other solution would have been the
better choice, we'd either end up braking backward compatibility or
having two solutions for very closely related issues thus increasing
confusion and error-proneness.

> [...] Hence featers grow left and right and it is
> hard to keep the whole system at least on some level of
> consistancy.

Reaching some undesirable level of inconsistency is exactly what I'm
trying to avoid ...

> 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.

Which is a perfectly valid and reasonable approach. However, in this
case, an alternate solution is available which, imho, should be taken
into account as well.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090503/c59e143b/attachment.bin