On 25/10/11 17:18 -0400, Matt Wagner wrote:
On Mon, Oct 24, 2011 at 04:03:30PM +0100, Martyn Taylor wrote:
> Hey Matt,
> Good find. I deffinitely agree! From reading around it seems this is
> certainly an issue and resources aren't particularly easy to come by.
> However, I think we should add this to configure rather than in the
> RPM. This is essentially what we have configure for. There are also
> other security concerns that are addressed through configure, such as
> setting up SSL on conductor, OAuth on iwhd and factory etc... So I
> think this fits in fine.
Thinking this over a bit, I'm not sure I agree. I think it's important
that the RPM results in a secure installation out of the box.
The difference I see here and with SSL/OAuth is that those are enhanced
security features between components, while this is fixing an
exploitable security flaw.
If we are going to use aeolus-configure for this, I'd move that we
delete secret_token.rb entirely from Conductor so that Conductor is
non-functional until aeolus-configure is run.
I tend to agree with Matt here, I think this should be part of a
default install, as it is completely unrelated to other components.
However, I am a bit on the fence. The app isn't really usable until
you run configure anyway, since that is what sets up your DB, initial
user, etc. On the other hand, if you are doing an _update_ and have
the old unsecure token, it would make the most sense for you to get it
for free with an update and not have to rerun configure (which at
least at one point would reset all your data anyway, which you may not
want on an upgrade).
Maybe there is a way to cover both of these concerns? What if we did
something like matt suggests, and not ship the secret_token.rb file in
the rpm. In the case of a new install, configure lays down the file
(though I am a bit dubious about possible effect on cleanup on a yum
erase operation), running some variant of the rake task from the
patch. On an update, if the file exists, the conductor rpm runs the
rake task to update the existing token. Hmm, and I could be off here,
but cant puppet be configured to be automatically triggered by certaon
events? If so, it could _always_ handle the token generation,
creating a new one on each update _or_ install.
I think I did not help you make a decision there, but hey, you asked
for opinions... ;)