What about Use-case 1a; The evil hacker who hypothetically stole
David's private key operates out of the Bahamas, and regularly uses
the hotel lobby network to work his/her evil? (Not horrible unless
Eclipse is the target)
Or worse (1b): Said hacker happened to be paying attention to what
he was doing and also knows he's vital to releases at Eclipse...
(thereby identifying the target org as well)
Would there be a mechanism to flag a network "trusted" for a very
brief time period, so that exposure would be more limited?
-Eric
On 28/09/2011 1:01 PM, Denis Roy wrote:
We track IP networks per user; however, once a
network is trusted by someone, it is trusted for all.
On 09/28/2011 12:13 PM, Igor Fedorenko wrote:
Out
of curiosity, do you track trusted ip networks per user or
independently from any user?
--
Regards,
Igor
On 11-09-28 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*
EclipseCon Europe 2011 <http://www.eclipsecon.org/europe2011>
--
Denis Roy
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
