Re: [cross-project-issues-dev] Why allowing Hudson to write to your down

[Kim Moir <Kim_Moir@xxxxxxxxxx>]

+1 to Ed's comments

We can only mitigate the security risks
to a reasonable extent.  When we start compromising our ability to
do our jobs and produce builds for our consumers due to very expensive
overhead of verifying each that each build has not been compromised, we
might as well stay home.

It's similar to the risk of dying in
a car accident.  It's a 1 in 4000 lifetime risk (See http://www.dangardner.ca/index.php/books/item/16-risk-the-science-and-politics-of-fear).
 We wear seatbelts and cars are equipped with air bags to reduce this
risk.  Nevertheless, deaths still happen, but we accept the small
probability of risk for in return for the reward of convenient travel.

Yes, it's unfortunate that other open
source sites were hacked.  But if our fear of being hacked means that
our processes grind to a halt, the hackers have attacked us too.

Kim




From:      
 Ed Merks <ed.merks@xxxxxxxxx>
To:      
 cross-project-issues-dev@xxxxxxxxxxx
Date:      
 09/14/2011 10:28 AM
Subject:    
   Re: [cross-project-issues-dev]
Why allowing Hudson to write to your downloads is a Bad Idea.
Sent by:    
   cross-project-issues-dev-bounces@xxxxxxxxxxx

---

Denis,

Comments below.

On 14/09/2011 7:09 AM, Denis Roy wrote: 
On 09/14/2011 10:02 AM, Ed Merks wrote: 
I agree with Doug.  

At no point have I seen anyone answer this question:
 What can be done manually to determine if what's
produced by Hudson is compromised or not?
Off the top of my head:

1. run a build on a remote system and compare the pre-signed binaries.
Compare binaries? Builds often produce different results
because some aspect of a time stamp is encoded in the build result, e.g.,
the qualifier...  (Eike was telling me that his Javadoc build produces
different results from time-to-time when applied to the same source.)

Getting one build working is already a huge challenge getting two producing
identical results.  Have fun release engineers....

2. run a past build and compare today's binaries with those in the past.
Same problem as before.  We do expect each build
to be different.  So this suggestion comes down to replicating builds
such that they produce identical results and then relying on the replicas
having different security characteristics such that they won't both be
compromised in the same way.  It's a nice idea, but, good luck to
the release engineers on that one...

3. run a build and examine the execution trace.
I can feel my brain overflowing and numbing just at the
thought of this. 

4. run a build, run the executable and examine network output for unknown
activity.
When I hack it, I'll make sure it doesn't do anything
until the 10th time someone runs it, or until the next leap day, or at
a random point in the future.



I also have to question whether this change during the
SR1 shutdown phase is appropriate timing...
Go download the latest Linux Kernel from Kernel.org and
tell me if there is ever a more appropriate time than 'now' to discuss
security.
No, but it's still a reasonable question.  In the
end, it's all about balancing risks and so intelligent people will differ
in their opinion.

Denis



Regards,
Ed


On 14/09/2011 6:55 AM, Schaefer, Doug wrote: 
I'll come back to something Dave Carver mentioned
yesterday. If we don't trust Hudson, then we shouldn't be using it, or
at least should be wrapping it up in tighter security, like a VPN for example.
If someone is going to do something malicious and they're smart, you're
likely not going to be able to discover it. You have to cut it at the source.

And is this not an issue other Hudson/Jenkins users have run into? What
are they doing for security. Or do they trust Hudson as much as they do
ssh.

Doug.




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev