eeZi
Born on June 01, 2014•824 Karma
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.
[0] https://twitter.com/iangcarroll/status/830878517730623492
[1] https://developer.apple.com/documentation/security/1644033-s...
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)
`minishift` seems to be similar to `minikube`. On my mac, running `minikube start` successfully starts a minikube instance in Virtualbox.
Unfortunately `minishift start` seems to sit there and fail after 120 seconds (with xhyve and vbox) because "the docker-machine didn't report an IP address", and it seems that the docker-machine is not even created.
This is a shame, I'd very much like to try out openshift. If anyone else has the same issue here please let me know!
Edit: Someone replied but deleted their comment. I should have run `oc cluster up --create-machine`!
That being said, I do run a few 2-3 node OpenShift clusters and the additional complexity was well worth it.
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.
Care to give some details about this and other failures? Part of what makes a FS reputation is not just people telling "it works" but also stories about how the thing crashed and how they recovered from it. IOW, it always works, until it doesn't, and then it still "works" because I can dig myself out of the hole this or that way.
Inspired by the way you can convert a Debian VM to Arch Linux on Digital Ocean, I happen to have been toying with it recently to auto-convert a blank Debian 8.x VM from ext4 to btrfs. Looks like things are fine, but only because the kernel is <4.x and the VM has very little data on it since it's blank.
WARNING: This is a toy. Do not use for production.
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.
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?
> We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions.
Where do you see that chrome apps are being discontinued? Otherwise this is FUD.
The only upside I can see is that CrOS is soon going to support running Android Apps which may save it, but even then... Maybe they'll figure out a way to run Electron/NWJS apps on ChromeOS?
Postman aside, I don't understand why anyone would want any of the apps you listed to be installed as a Chrome App. Why would someone want an SSH or TeamViewer client to be tied to their browser? You're installing an application either way; Chrome internalizing the process as an attempt to offer convenience is a strange idea. Chrome is a browser, not an operating system - let the OS do what it does best. Chrome Apps were an unnecessary and proprietary mess - a failed experiment I am happy to see dismissed.
- unblockable advertising
- stronger DRM
- Bitcoin mining that regular user can't detect
- etc..
It will be good and bad, but, more bad than good.
We could choose not to run .exe .bat and the rest
So far, webassbly doesn't look optional.
Ad blockers primarily look at domains, so blocking will continue to be possible at the request level. They aren't interpreting or parsing JS to begin with.
> - stronger DRM
If sites were going to ship Web Assembly-based DRM, they would already be shipping Web Assembly along with the Emterpreter. Remember that wasm has a polyfill already. I haven't seen that happening, so I see no reason to believe it'll happen in the future.
> - Bitcoin mining that regular user can't detect
A regular user certainly would notice the 100% CPU consumption. And anyway, bitcoin mining in a WebGL shader would be more profitable than anything wasm-based.
Moreover, though, surreptitious bitcoin mining on consumer PCs would be ludicrously unprofitable no matter what. Here a Stack Overflow answer from last year that calculates how much a site with 2M daily visitors would make if they could all somehow run the fastest C implementation [1]. It was less than 50 cents a day back then, and in the meantime the hash rate has grown by nearly an order of magnitude [2]. Good luck.
[1]: https://bitcoin.stackexchange.com/a/42413
[2]: https://blockchain.info/charts/hash-rate?timespan=2years
One cool idea that is also gaining traction is in-browser proof of work to prevent DDOS attacks. Basically you have to perform a lengthy computation to get past the (fast, ultra-high bandwidth) firewall. Doesn't slow down the individual user much, but makes an attack much more difficult. I could imagine people using malicious JS to get these proof-of-work tokens.
But yeah, computing power in the cloud has become fairly cheap, it's really hard to see how criminals could benefit from secretly serving WebAssembly to people.
I think it would be smart to educate people as part of a regular security briefing for non technical staff though. But if it's something that high of concern to your company maybe an automated CPU usage monitor could alert the team to anomalies.
[1] I was running a test today when the program being tested ran into a very tight loop and the fan really kicked in. I was curious if it would finish and let it run for several minutes until all went quiet and the screen went dark. It had shutdown to prevent heat damage.
A laptop overheating from few minutes of 100% CPU is not normal.
First, I don't see why you think WASM-based ads will be any less blockable than JS already is.
Stronger DRM on the web [is already a thing][1], but that has nothing to do with WASM.
Bitcoin mining on the web is already possible with JS and so far that hasn't been an issue. If it does start becoming a widespread problem though, browsers will start taking steps to combat it, like they [already have][2] for pages that needlessly consume CPU in the background.
[1]: https://www.w3.org/TR/encrypted-media/
[2]: https://developers.google.com/web/updates/2017/03/background...
That's actually a great idea for funding content creation online. If a site is open source, then it would even be possible to prove that only a reasonable share of the client's resources are being utilized. I'd take that funding model over the advertising-driven model that exists now.
I don't see how this necessarily follows from WASM.
I just cannot see this not happening.
The reason people don't do this, is because ad companies want control. They want to know exactly how often the ads are served and they don't trust you to serve their ad all the time and to all customers. Also they want to rotate it quickly. Finally, they want to track people. So the solution is to use remote javascript. 99% of ads work this way, even mayor news sites don't sell their own ads anymore.
In this scheme, you'd probably still have ads served from a third party server. And even if they obfuscated the domain name, you could still probably identify their blob and block it.
So I'm not to worried about unblockable ads. But you're right, they will try, and I am worried about sites becoming unusable because they will emulate browsers using canvas, poorly.
As for the site owners - unless it's someone large enough to care, I think the usual choice between "letting a few disabled persons access the site" and "getting a few more bucks from advertising" would be quite obvious. If that question would even arise.
It makes very little sense to mine on anything other than ASICs.
CPU mining hasn't been viable since 2011 when bitcoin difficulty was below 1,000,000, and today it's near 600,000,000,000.
What do you mean?
Google could have allowed Chrome to be used as a cross-platform GUI library (THE cross platform GUI library), but left it to Electron (lagging behind and requiring distribution); think XUL runner. I don't see the sense in that. I'd absolutely love a modern XUL runner.
Electron is really just Chrome with a separate JS engine that can run native code if the developer chooses to do so.
Personally I'd argue that the "nativeness" of an application depends on how much the developer actually uses that ability to run native code. If you just throw a bunch of standard webapp CSS, JS and HTML in a folder and wrap Chrome around it, it's no more "native" than any other webapp. If on the other hand you have a whole bunch of native code doing, for example, media editing and the HTML and such is just the frontend UI, I'd say sure, that's a native app.
Oh, the tragedy /s
eg: I'd like to build an expense tracker with html/css/js/sqlite but I want it to be offline and the user can choose to save their db file in their dropbox/gdrive folder.
It would be more accurate to say it was the best thing to happen to your use of Linux in a long time, and it looks like even that is only because you're trying to use a bunch of closed source, non-cross-platform stuff.
I also disagree that it makes users less secure. The teams working on Debian, Ubuntu, Arch, etc. have much better security track records than some random web developers who've made an "app". There's no way would I trust a web based SSH client, for example.
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 :-)
I have a hard time believing that. With a ton of stuff all running inside of Chrome, it's much easier for them to access each other's data than if they were standalone apps. Further, since Chrome is such a huge attack surface, I would expect it to be less secure than a smaller, more specific application.
On that note, I can go look at my Linux distro's security and bug tracking systems and see all of the known security issues and bugs affecting almost all of the software on my system. Does anything like that even exist for Chrome Apps?
> If, for example, the Cleanflight or TeamViewer apps were regular apps, a bug in them would fully compromise my account.
Isn't that the case whether it's a Chrome App or not? Chrome has a huge attack surface, so it seems there's an even bigger chance of hitting a bug or being affected by an exploit.
The bigger problem seems to be that you're running apps that you don't trust, while I can trust my Linux distro to have safe software in their repositories. Barring bugs, I generally don't have to worry about installing malicious applications.
I'm not sure Google does any kind of vetting for Chrome Apps, but I'm not sure I'd trust them even if they did. They are the largest ad tracking company in the world after all.
> I have a hard time believing that. With a ton of stuff
> all running inside of Chrome, it's much easier for them
> to access each other's data than if they were standalone
> apps.
If you're using X11, every command with access to the display server (which is usually everything you run) can read all keyboard and pointer input and screen output and inject arbitrary input.
The only reason that's even a concern is because you can't trust Chrome Apps to not be malware.
On the other hand, when I "apt-get install <some app>" I know it's not listening to all X keystrokes unless that's a legitimate part of its functionality, because I trust the Debian team to only add trustworthy software to their repos.
Chrome apps are subject to sandboxing, and regular native desktop apps (besides apps installed through OS X's app store) generally don't have any sandboxing enforced on them at all.
Taking Soundcloud as an example, Clementine (and probably most media players) can stream it just fine. Having a Chrome App is nice, but it isn't providing anything that isn't already available. I'd even say the Chrome App is a step backwards, because with Clementine I don't need a separate app for every music service.
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.
Is that true? Executables and shared object files are supposed to share (code) memory.
So what big data structures does Chrome use that it can share between tabs (which are processes) and that it can't share between different instances of Chrome?
I will disagree, you can install most of these from the official repository of your distribution, without the use of electron. They are also very secure if you run them as an unprivileged user.
1.) Port it to Electron and keep nearly the same code base
2.) Rewrite the whole thing as a native app in such a language as C++ without the use of Electron
You can't possibly tell me that most developers won't choose #1 instead of #2 in a heartbeat (the switching costs are orders of magnitude more for #2, for one thing). Which is not a Good Thing.
And it's also very obvious that #2 isn't nearly as secure as #1, which runs in a sandbox and so does not have direct unchecked access to users' files like #2 does.
Seriously? There are like 12389127381789 how to guides about how to do it, and it is literally like 3 steps.
Do you really think the person who has problems starting putty is going to thrive in a CLI environment?
10/10 developing for the web on windows is finally tolerable
Cygwin has ssh as an optional install.
Msys2 too.
Of course, you need to have windows first. MS give away 30-day win 10 trial VM images with git bash installed, or at least they did.
The idea that software is secure if it only runs on your own user account is stupid IMO. I'd rather that software had access to everything on my computer EXCEPT my personal files.
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.
I know, I know. It's crazy talk....
So it was just kind of a snarky joke because the parent said that to be a "Linux Desktop" you had to be able to get ssh running (presumably they meant openssh). And while that's not GNU, GNU is what the vast majority of "Linux Desktops" will use to get you there -- so the implication really was that "Linux Desktop" == "GNU/Linux Desktop".
I thought it was funny, but probably I was being too obscure. Also, I should know better than to dive into politics for no good reason.
Say what? Do you know what GNU means or what it includes? Here's a link so you can learn more:
I think there is some value in denoting 'linux the kernel' from 'linux the unix-like system', especially in the face of those systems which mainly use 'linux the kernel' in a non unix-like way, such as here..
e.g.: the 'gnu parts' (e.g. unix-style userland) are hugely important for me in a workstation - I could not do work in a system that doesn't provide the 'gnu(unix) like' user interface. On a phone/consumer/browser device, this is not so much the case
This reply is a bit overly pedantic and I apologize, but you kept pushing so I wanted to clarify.
https://groups.google.com/a/chromium.org/d/msg/chromium-hter...
But "if everything aligns" == "only if you're inside Google".
Makes a lot of sense sense since Chrome OS is much easier to secure than a normal Linux distribution.
Google also has goobuntu, which I'm being is what's provided to engineers.
I tried it for a while, but I'm too used to the Mac to have made the switch more easily, so I moved back. But I know quite a few folks who use and love them. Opinions, as I'm sure you can guess, vary widely. It was surprisingly not-bad, even for a diehard mac user, and that was on a model from two years ago.
That seems unlikely, if only for the security implications (would apply to any laptop of course, nothing to do with macos or chromeos)
Google is a very large engineering organization, and (my opinion here, but one shared by others) recognizes that there's a lot of diversity in what engineers like for their workflow. There's obviously a set of standards for what you can choose from as far as laptops (since the company is buying them), but it's pretty broad.
Here's a Quora answer that goes into more detail: https://www.quora.com/What-computer-or-laptop-do-software-en...
You can read more about Google's security model in a USENIX ;login article from last year: https://static.googleusercontent.com/media/research.google.c...
(source: The above cited sources, plus I'm part-time at Google.)
https://mikecborg.wordpress.com/2017/03/22/securing-clouds/ (search for all occurrences of 'chromebook')
I still listed it for completeness, I do use it, after all.