Le 26 janvier 2011 à 15:25, David Voit <firstname.lastname@example.org> a écrit :
> >> > 2.) Do we really need client authentication, for every component? For
> >> the
> >> > arbiter, sure we need it - else we get a botnet like system. But the
> >> other
> >> > components?
> >> > Reactoner and broker, need to authenticate too, else the "bad guys"
> >> > could get secret data (all theoretical)
> >> I'd say yes, all components must securely connect to others to avoid any
> >> security breach.
> > Yes, there are list of servers and some things like that. It's better to
> > crypt all of this if the admin want it. and it's not so harder to add such
> > feature for all daemons, and after all, it's already done :p
> It's not about encryption, it's about authentication. If you call a https
> site, all the traffic is still encrypted, even without a client cert.
> You are responsible, if you connect willingly to the bad guys. With shinken
> we have a problem, if the arbiter is not authenticated, couse it could send
> any shell code, to all instances after it.
I was effectively speaking about authentication, not encryption ;)
I pointed that authentication need out few weeks ago, and effectively, without authentication layer, an arbiter can send arbitrary commands to any scheduler (tested).
But with the authentication layer added this should be ok (note I didn't make more tests for now...)
> > We discussed also on the future possibility to make the certificates> >> creation automatic for components (scheduler, poller, roker, reactionner),
> >> like done in the Prelude IDS project.
> >> > I also recommend that we don't ship certs with the tarball, but
> >> generate
> >> > them at install time.
> >> +1, I've already pointed that out ;)
> > Yes, it can be a very interesting feature :)
> > I don't know where is the best place for this (hook in setup.py or in the
> > packager code for installing)? Is ther a packager guy to help us on this
> > point? How is this thing manage in the other projects?
> I would say on both sides. setup.py for the developer and gentoo typed guy
> :-). The package way for everybody else.
> The apache2 package does this on suse (not checked, from memory).
One side should be easier to maintain that several.
I think setup.py is definitively not the best place for this, as it's main aim is to install the code.
CA and certificates generation is a more external and manual postinstall task.
So, I would provide in the Shinken distribution a standalone script for CA and certificates generation, that packagers will fire in the postinstall process of their packages, and that sysadmins will use when installing Shinken manually.
But remember the CA and certificate creation should be optionnal, as many sysadmins already have CA management tools and will use it rather a script ;)