eeZi
Austria, Switzerland and Germany have a very long rock climbing history (unsurprisingly), and their respective climbing associations are obsessed about safety.
Having a UI does not increase security in a meaningful way. The attacker is just going to wait until the victim connects to an interesting target server and then hijack that connection. The ControlMaster feature makes that trivially easy, but it's not hard to do real injection [1].
If the workstation is compromised, it's over.
At that point, all you can do is to prevent an attacker from copying the key or using it without user interaction. A YubiKey does both - you can optionally set it to a mode where you have to approve each signature.
With a bank transaction, the whole transaction is part of the approval process and can be verified out-of-band. With a SSH login, this is not possible since you're still going to trust the workstation as soon as the session is established.
I'm not saying this project is useless - IF your phone is actually more secure than your workstation - which may or may not be the case - AND you've been previously been storing your keys on your workstation, then it's definitely a step up. But really, at that point, just buy a YubiKey (and properly secure your workstation!).
Otherwise, you now have TWO single points of failure instead of one. If either your phone or your laptop is compromised, it's over.
If you want login approvals that show the server name, do it as a second factor and use something like Duo Security with push approvals. This actually increases your security - instead of having, an attacker would now have to compromise both of your devices.
That being said, I do run a few 2-3 node OpenShift clusters and the additional complexity was well worth it.
It's upstream Kubernetes + a PaaS framework built in top of it.
It takes care of role-based access control, has a secured Docker registry (prevents applications from pulling each other's source code), Jenkins integration and can automatically build, push and deploy your applications.
Our team started using it and it's great. The documentation is top-notch (it's probably the best docs I've ever seen in an open source project).
I've seen many teams re-invent the wheel over and over again, when OpenShift already does most of what they need.
Happy to answer questions!
https://www.openshift.org/ (`oc cluster up` and a running Docker is all it takes for a first test)
Someone on #btrfs said that the filesystem layout is a lot different when using the conversion tool and all of the regression testing happens with regular filesystems, not converted ones.
We reinstalled all machines from scratch. Never happened again.
With a Chrome App, it sits in a (really strong) sandbox and would need to escape the sandbox first.
With a native app, it's game over.
And sometimes, you have no choice - there's no FOSS alternative to TeamViewer, and thanks to it running inside Chrome, I no longer have to run a Windows VM.
The web based SSH client is published by Google themselves and they use it internally.
> The teams working on Debian, Ubuntu, Arch, etc. have much better security track records than some random web developers who've made an "app".
The way things are, right now, Chrome is much better at protecting apps from each other than my Linux desktop is. If, for example, the Cleanflight or TeamViewer apps were regular apps, a bug in them would fully compromise my account.
---
Off topic remark about Linux distro security: I really like Arch, but security isn't their strongest suit. For example, they still haven't enabled full-system ASLR, citing unfounded performance concerns, when other distributions did so years ago. Even Windows with all their third party apps has a higher percentage of ASLR binaries than the average Arch system.
They also have no central build system and instead rely on volunteers who build the packages on their personal systems and sign them using their personal GPG keys.
I really want ASLR in Arch so I'll keep complaining about it publicly until it finally happens :-)
Makes a lot of sense sense since Chrome OS is much easier to secure than a normal Linux distribution.
Chrome Apps were great because they worked on all (desktop) platforms.
I still listed it for completeness, I do use it, after all.
https://chrome.google.com/webstore/detail/secure-shell/pnhec...
It's useful outside of Chrome OS if you have a security perimeter based on TLS with ACLs and auditing already in place and you want to use it for SSH as well:
https://github.com/zyclonite/nassh-relay
https://chromium.googlesource.com/chromiumos/platform/assets...
Google uses a similar setup internally.
Had a LOT of unplanned downtime due to various issues with older kernel versions, but 4.10+ has been solid so far. You definitely need operational tooling (monitoring, maintenance like balance) and a good understanding of the internals (what happens when you run our of metadata space etc.).
Happy to answer questions!
On a related note: Never ever use the ext4 to btrfs conversion tool! It's horribly broken and causes issues weeks later.
Some examples of specialized apps I use all the time that would require a native app otherwise:
- Signal Desktop
- TeamViewer
- Postman
- SSH client
- Cleanflight drone configuration tool
It was one of the best things that happened to Linux desktops in a long time and removing it hurts users and makes them less secure.
Now everyone is moving to Electron and instead of one Chrome instance, I'm now running five which use more than one GB of RAM each. Much less secure, too, since each has its own auto-updater or repository and instead of being sandboxed by Chrome's sandbox, they're all running with full permissions.
It also means I cannot longer use Signal Desktop on my work device since installing native apps is forbidden for good reasons, while Chrome Apps are okay.
It also hurts Chrome OS users since Chrome Apps are being abandoned in favor of Electron. It also makes it less useful for developers to create Chrome Apps since the market is much smaller.
Since Chrome Apps continue to be available on Chrome OS, I'm considering separating that functionality into a stand-alone runtime or making a custom build for Linux. Anyone wants to help with that?
- clean Unicode support which prevents mistakes which used to bite us in production
- native async syntax, compatible with Tornado
- asynchronous generators (yield from a coroutine!)
- pathlib and os.scandir
- type annotations
- matrix multiplication
- chained exceptions
- faster dicts, ordered by default
So many useful features, and with the latest Python 3 releases porting has become really easy thanks to improved compatibility with the old syntax.
Client side code has to run on everything starting with CentOS 6, so they have to stick with Python 2 for a long time.
For the Ansible master (which runs on the management machine), Python 3 porting work is already underway.
Haven't had a single Unicode bug in production since we switched to Python 3. Also, chained exceptions (extremely valuable in walled-off production environment).
Type annotations actually work and have prevented a number of bugs.
The asyncio syntax is really nice with Tornado (don't use aiohtto, use Tornado! it's much more mature)
This is Canonical's stance:
> All Ubuntu/Canonical driven development should be targeting Python 3 right now, and all new code should be Python 3-only.
Regardless, nowadays many people deploy Python applications as stand-alone bundles. We're happily running Python 3.5 on CentOS 6 and it took like ten minutes to deploy (pyenv!). This lets us use a rock-solid base system with an up-to-date application stack, which makes our old school admins happy.
Pretty common - many community distros do. Arch Linux too. Worrying for obvious reasons.
At least they're putting in an actual effort at making builds reproducible.
Doesn't mean we shouldn't try, since we're not getting rid of if anytime soon.
Google's Certificate Transparency is a great approach.