Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Security changes to SSH and shells explained

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.


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?
ocal 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 and not

dev| run a patched kernel to support the large number of groups that many committers belong to, whereas 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  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 only.  SCM operations occurring on dev| 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  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 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

            Europe 2011
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx

Back to the top