On 09/13/2011 08:30 PM, David Carver wrote:
The
only safe way is to shut down Hudson
I like it! Where do I sign? :-)
FWIW, Hudson currently _can_ publish to download.eclipse.org if you,
the committer, set up the ACL to allow it. However, I strongly
believe it is a Bad Idea, I will not do that set up for you, I have
provided you with information to allow you to decide whether that is
a sensible approach or not, and I have provided what I think is a
reasonable alternative should you happen to agree with me.
That is all.
Denis
Dave
On 09/13/2011 05:56 PM, Denis Roy wrote:
On 09/13/2011 04:31 PM, Thomas Hallgren
wrote:
On 2011-09-13 21:57, Denis Roy wrote:
If someone exploits Hudson, I doubt
they are going to actually run your build job. All they
need to do is upload content and new checksums directly to
the downloads area to replace your most recent release.
That would raise no red flags :)
But does that matter really? Let's say all projects create
some kind of promotion script that copies the Hudson output
If we assume that Eclipse Member companies are currently
downloading your binaries from the Indigo release stream and
packaging them into their commercial applications, then
preventing Hudson from altering those Indigo binaries
after-the-fact really matters. I think it does, anyway. If you
disagree, I'd like to better understand how.
In my original email, I was suggesting that you perform some
kind of validation that the build output you are about to copy
is sane, where 'sane' can be as simple as 'weekly builds run at
10:00am on Wednesday, don't copy anything else'.
When Indigo was released, the Hudson build output wasn't just
placed up for downloads without many eyeballs scrutinizing it.
This sanitization may not be required for nightly or weekly
builds, but for official releases to be consumed by the general
public, as a consumer I would be disappointed if projects didn't
ensure their binaries were safe.
I think we have to trust Hudson and the
plug-ins that we install.
Of course we do. We also trust Linux, the Apache web server and
all the other software packages that are on Eclipse.org. But
realistically, that doesn't mean those packages cannot be
exploited in ways unknown to us today by someone, somewhere, who
is just waiting for an opportunity to cause us harm.
If we don't, then we will need very
thorough checks of all material that we promote to the
download area at all times.
As Eclipse enters embedded, runtime and server markets, doing
that would be a bad idea? Does no one run a network sniffer to
see if Eclipse, or any other software, is sending out random
data to the world? Surely I'm not the only one who periodically
examines my personal network traffic to see what I'm saying...?
Just removing the ACL will not increase
the security.
That is incorrect. As I've explained, removing the ACL (ie, not
allowing Hudson to write to the general downloads area at all)
will limit the scope of any damage to that of a single
committer's account running a publication process. Since your
publication process doesn't involve overwriting files created in
the past, the beginning of any potential damage would be easy to
discern and have a clear point-in-time.
Of course, if committers insist their promotion script simply
copy $A to $B without any validation whatsoever, then we should
just chmod 777 the entire downloads area and be done with it.
But if something breaks, don't ask me to fix it :-)
All in all, this discussion illustrates that implementing a
centralized publishing process would go a long way in solving
these potential problems...
Denis
Regards,
Thomas Hallgren
Denis
On 09/13/2011 03:48 PM, Igor Fedorenko wrote:
Denis,
Can you elaborate on the suggested promotion job approach?
What are the
security advantages of forcing extra layer of automation
in this
particular case? I am not a security expert, but if Hundon
instance gets
compromised and changed to produce "bad" artifacts with
"good"
signatures and checksums, wouldn't the promotion job make
these
bad artifacts available from download.e.o?
--
Regards,
Igor
On 11-09-13 3:28 PM, Denis Roy wrote:
While we're in a
security-conscious frame-of-mind...
Many projects allow the Hudson user account to write to
their download
directories. Projects use one of these two ways to do
this:
1. They add an ACL on their download directory that
allows the Hudson
Build user to write there.
2. They chmod 777 their downloads directory, thus
allowing everyone full
access to their downloads directory.
Most of you understand that #2 is a clear violation of
any kind of
security we hope to maintain here at Eclipse. *Don't do
it. Please ask
us for alternatives.*
While #1 may seem like a better option, it has
implications. Allowing
Hudson to alter downloads means that other committers
can alter your
downloads via a Hudson job. I am not worried about this
since I trust
our committers.
The issue is about *trusting a public-facing
application* (Hudson) *and
all its plugins*, each of which may contain security
vulnerabilities. If
unauthorized control of Hudson was achieved, downloads
could be replaced
with compromised ZIP and JAR files.
As Hudson can sign on behalf of the Eclipse Foundation,
compromised
downloads would appear authentic with digital signatures
and valid
checksums. A keystroke logger could leak sensitive
credentials to a
third party. This is how unauthorized root access
begins. Far-fetched?
Not at all.
The above is not a stab at Hudson, Winstone or any other
specific
software -- all software may contain a vulnerability,
including the
Apache webserver and the Linux Kernel.
Hence, I *strongly* recommend you use a promotion job on
build.eclipse.org which publishes known-good content
from Hudson. A
simple script which reads a state from Hudson, runs some
sanity checks
and wget's files and saves them in the downloads
directory is a great start.
I appreciate your taking the time to read this. My goal
is not to
encumber you with senseless, counter-productive dogma,
but to strike a
balance between security and convenience... with a
slight bias towards
security :-)
Denis
|