Now that some of the dust has settled on the recent
security issues, I thought it might be good to provide a bit more
insight into what your evil webmasters have done, and what they
have planned, in an effort to maintain high levels of security.
What are you so afraid of?
My biggest fear is that someone obtains root access on our
servers, potentially exposing our binary downloads, source code,
code signing certificate, SSL certificates, private information of committers, users and member organizations, and more.
Why strip everyone's shell access?
Local shell access is the easiest way
to install software that exploits vulnerabilities to obtain root
access. Although we trust our committers, active shell access is,
and has always been, our biggest cause for concern.
Why restrict the shell to build.eclipse.org and not
dev.eclipse.org?
dev|git.eclipse.org run a patched kernel to support
the large number of groups that many committers belong to, whereas
build.eclipse.org uses the Novell-shipped kernel, making it easier
and faster to deploy a new kernel on build.
But I use keys to log in, isn't that safe?
Your private key is stored in a file in a standard location on
your computer, and is available to any piece of software (and
malware) that is running as your user account. If someone obtains
a committer's private key, they can log in to our servers
unchallenged and undetected, where they may have full shell access
for weeks, months or years.
So how will you keep our Shell-Enabled accounts safe from key
(or password) theft?
A simple mechanism is now tracking the IP networks from which
shell accounts are used on build.eclipse.org. Soon, when we're
confident it has sufficiently learned your login patterns, that
mechanism will block a successful login from an unknown
network. An email will be sent out to you, and the simple
act of responding to that email will place the unknown network in
the trusted list for all.
If the trusted network is not used by anyone for more than two
months, it is no longer trusted.
This mechanism only applies to committers with full shell
access logging into build.eclipse.org only. SCM
operations occurring on dev|git.eclipse.org will not be subjected
to this scrutiny since there is no shell access on those servers.
Typical use case I:
While on vacation in the Bahamas, David Williams is committing
from a hotel lobby. Although David has a full shell, his commits
are unchallenged on dev.eclipse.org. After successfully opening
an SSH shell on build, he is instantly kicked out and notified via
email. After replying to the email, his subsequent logins
succeed. Weeks later, back in the USA, David receives an
unexpected notification that his account was used successfully
from a computer in Spain. He then realizes he should not have
left his computer unattended while ordering that last margarita in
the Bahamas, and proceeds to inform webmaster that his private key
has been compromised.
The would-be hacker in Spain is left with a closed SSH session,
and can no longer connect to any eclipse.org server.
Typical use case II:
While at EclipseCon Europe, an elite group of hackers posing as
Obeo committers proceed to distract the webmaster with endless
praise and numerous free drinks, and use his laptop. Although
none of the impostors speak French, the webmaster is unaware that
his private key is now compromised. The next day, the webmaster
awakens to a headache and email notifications that usage of his
account has been blocked. A compromise is avoided, and the
impostors frustratingly return empty handed.
We estimate this mechanism will cause very minimal
inconvenience to you, while offering us excellent protection
against private key and password theft.
Thanks for reading. If you have any questions or concerns, please
contact Matt and I at webmaster@xxxxxxxxxxx.
--
Denis Roy

|