While all of the below sounds great, how about before we cut
everybody off or make it a bit more difficult to do what we need to
get done as committers, that we setup the infrastructure so that I
DON'T need shell access at all to do what I need to do?
This includes items like deploying artifacts to the appropriate
places, staging p2 repositories, and requesting/creating hudson
related jobs.
I know that their is work undergoing for a redesign portal, I'd love
to see some of the functionality that we used to have to do via the
shell access moved to the Portal. Eliminate the need for Shell
access entirely, otherwise this is just a bandaid, and if somebody
really wants to get into the servers, they'll find a way to do it.
Dave
On 09/28/2011 10:56 AM, Denis Roy wrote:
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
