Great discussion between @atd & @ryan about Blockstack Portal’s security model in slack yesterday:
@atd [1:46 AM]
@ryan what is the name of the app you just sent me?
@ryan [1:46 AM]
https://github.com/blockstack/blockstack-portal
github.com
GitHub - blockstack/blockstack-portal: The Blockstack Browser Portal
blockstack-portal - The Blockstack Browser Portal
[1:46]
This? ^
@atd [1:46 AM]
ah thanks
[1:46]
so is this just the cli, with a webserver that renders the frontend
@ryan [1:47 AM]
Here’s an extension I whipped up for it: https://github.com/blockstack/blockstack-portal/blob/master/extension/src/index.html
github.com
blockstack-portal/index.html at master · blockstack/blockstack-portal · GitHub
blockstack-portal - The Blockstack Browser Portal
@atd [1:47 AM]
plus dropbox to store user data?
@ryan [1:47 AM]
<iframe src="http://localhost:3000"></iframe> </body>```
[1:47]
LOL ^
@atd [1:47 AM]
lol
[1:47]
lol we’re gonna have to fix that
[1:47]
your http is missing an s
@ryan [1:47 AM]
yeah dropbox stores user data, only option for now
[1:47]
we’re adding more options
[1:47]
ha we need https on localhost
@atd [1:47 AM]
so what if you had a chrome extension
[1:48]
and a bridge
@ryan [1:48 AM]
what’s a bridge?
@atd [1:48 AM]
bridge could be a local cli
[1:48]
but does that have to be local?
[1:48]
couldn’t I use a remote server and https?
[1:48]
have the extension render the frontend
[1:48]
and store the data in dropbox?
@ryan [1:49 AM]
it does not have to be local
@atd [1:49 AM]
not saying there is anything wrong with the way it is by any means
[1:49]
I have a use for it
@ryan [1:49 AM]
chrome extension is another option totally
@atd [1:49 AM]
but I think if you do a remote cli with an ex
[1:49]
ext*
@ryan [1:49 AM]
only thing is we’d like for users to have full local blockstack nodes
[1:49]
that’s ideal
@atd [1:49 AM]
you remove the risk of running a server
@ryan [1:50 AM]
what do you mean by risk
[1:50]
if you run your own node, you don’t have to trust a remote node
@atd [1:50 AM]
yes but you have an open port
@ryan [1:50 AM]
it’s not running on port 80
[1:50]
it’s not exposed
@atd [1:50 AM]
http://blog.blindspotsecurity.com/2016/06/advisory-http-header-injection-in.html
[1:51]
I’ve just seen some crazy python zero days that make me worry about running a server on the machine if we don’t have to
@ryan [1:51 AM]
ahh
@atd [1:51 AM]
to handle this at 21 we put all the python within a hardened alpine build, within docker, and we had to customize the vm below that
[1:52]
well the hypervisor
[1:52]
zerotier tunneled out to avoid messing with the network
[1:52]
but that works until you have a zeroday
[1:52]
and once you have a zeroday, bye bye coins
[1:53]
I may be overly paranoid, but I assume the machine is compromised already
[1:53]
keys on a hw device, data in dropbox, and no local server tends to be the safest route
[1:53]
and from a useability standpoint
[1:54]
its a lot easier to install a chrome extension than a .app
[1:54]
the .app runs the risk of triggering the users firewall
@ryan [1:54 AM]
should totally use multi-sig with hardware devices for the coins
[1:54]
would love to support hardware devices soon
@atd [1:54 AM]
yesbut multisig doesn’t save you from ransom (edited)
@ryan [1:55 AM]
doesn’t save you from ransom on a 2-of-2
[1:55]
you’re correct
@atd [1:55 AM]
on any config
[1:55]
if they can encrypt your machine, you’re boned (edited)
@ryan [1:55 AM]
but with 2-of-3 you’re fine, assuming only 1 key was compromised
@atd [1:55 AM]
ah I mean my hacker didn’t care
[1:55]
he was demanding coin he deleted
[1:56]
if they can get root (either via an escalation similar to that cve), or via find my iphone
[1:56]
they’ll lock you out and just encrypt and wipe
[1:56]
until you pay up
@ryan [1:56 AM]
oh I see
@atd [1:56 AM]
they don’t have to compromise the coins themsleves
[1:57]
they just need to know you run blockstack and therefore have coin (edited)
[1:57]
beauty of the remote cli for the average user
[1:57]
is you can image it
@ryan [1:57 AM]
that’s where app sandboxing comes in
@atd [1:57 AM]
they can ransom it all day
[1:57]
sandstorm?
@ryan [1:57 AM]
the .app
@atd [1:57 AM]
ah what are you doing?
@ryan [1:58 AM]
I’m not as familiar with the containment there
@atd [1:58 AM]
so I haven’t found a good sandbox solution for mac
[1:58]
Kenton wrote this for linux: https://github.com/kentonv/home-container
github.com
GitHub - kentonv/home-container: Containerize your home directory
home-container - Containerize your home directory
[1:58]
works pretty well
[1:58]
This also works well on linux: https://github.com/netblue30/firejail
github.com
GitHub - netblue30/firejail: Linux namespaces and seccomp-bpf sandbox
firejail - Linux namespaces and seccomp-bpf sandbox
[1:59]
but is too large to audit
@ryan [1:59 AM]
ahh
@atd [1:59 AM]
so you end up with a docker container still
muneeb [2:00 AM]
I personally use Virtualbox on my OS X, started as GPLv2 and now lives with Oracle (via their Sun acquisition)
@atd [2:00 AM]
I do too ^
[2:00]
but the average user running say a macbook air
[2:00]
they’re going to struggle
[2:01]
I have some notes written down somewhere, after multiple cycles of Virtualbox a tmp folders called “cores?”
[2:01]
starts to fillup
[2:01]
takes up all your HD space if you don’t explicitly delete
muneeb [2:02 AM]
been meaning to try Kubernetes (as it should be more lightweight)
@atd [2:02 AM]
what I mean to say is, for your average user a remote cli might be better. For users that want to run the CLI themselves (me) it might be better to let them manage security
[2:02]
as I’d boot it up within vagrant
[2:03]
on mac, or simply on qubeos
[2:03]
I need to try kubernetes as well
[2:03]
hypervisor by the docker team right?
muneeb [2:03 AM]
Google wrote the manager but people usually use it with Docker (edited)
@atd [2:04 AM]
not meaning to be so negative lol
@atd [2:04 AM]
uploaded this image: Image uploaded from iOS
@atd [2:04 AM]
I’ve just been working through every vulnerability I can think of
[2:04]
lots of gotchas on my mind rn
[2:06]
we jammed the two1 lib into docker at 21
[2:06]
but then it became hard to run outside of docker
@ryan [2:06 AM]
ah
@atd [2:06 AM]
trezor’s model works well on mac and qubeos
[2:06]
and that is awesome
[2:06]
in qubeos I have to attach my usbs to a vm, then proxy them to other vms
[2:07]
so being able to separate all the components allows for some pretty interesting configs
[2:07]
I’m loving dropbox @@ryan
[2:07]
I wouldn’t want to store user data any other way
[2:08]
right now I use wine over debian to boot the windows version of 1password from qubes
[2:08]
dropbox syncs it to my ipad
@ryan [2:08 AM]
@atd [2:08 AM]
and that is over tor lol
[2:08]
and to even connect to dropbox I have to route the trezor through a usb proxy
[2:08]
airgapped syncing
[2:08]
I know that sounds complicated, but it really isn’t
[2:09]
I’ve ported blockstack-cli to qubeos
[2:09]
basically qubeos is what we are trying to emulate when we use macos with virtualbox and docker
[2:09]
except instead of macos you just have a xen hypervisor
[2:09]
there I would feel perfectly fine running the cli
[2:10]
well and its fast ^ on a mac I worry about performance and security is all
@ryan [2:11 AM]
oh by the way, we’re merging the CLI repo into the Core repo
@atd [2:11 AM]
excellent
@ryan [2:11 AM]
so it’s basically light Core and heavy Core
[2:11]
heavy comes with a blockchain indexer and builds the database locally
[2:11]
light outsources the name database to a heavy node
[2:11]
and does everything else
@atd [2:12 AM]
I see!
[2:12]
you want more heavy nodes right?
[2:12]
to strengthen atlas?
@ryan [2:12 AM]
yeah
@atd [2:12 AM]
or is it just a heavy cache
@ryan [2:12 AM]
Blockstack Portal comes with a light Core node
@atd [2:12 AM]
ah
@ryan [2:13 AM]
more light nodes helps of course
@atd [2:13 AM]
I’m absolutely fine with heavy ^
[2:13]
I’d jsut want to bundle its install with zerotier
[2:13]
so that the user only has to install once
[2:13]
I can write that code ^
[2:13]
for my use case
[2:14]
the zerotier GUI is an electron app, so I can merge it with the portal
[2:14]
meh I still worry about python talking to the browser without an nginx proxy or something
[2:15]
trycurl https://21.co | shon your mac, and then within a vagrant box
[2:15]
we over engineered it for the mac
[2:15]
and it sucks on debian
[2:15]
and is therefore unusable within qubes, which imho is prod for the end user
[2:16]
by over-engineered it, I mean we put a sandbox within docker, over virtualbox
[2:17]
works great on mac for one off use cases (it is secure)
[2:17]
but decoupling it to a modular OS like qubes is a nightmare
[2:18]
I am very likely to run chromium in one vm over qubeos, and the cli in another vm.
[2:18]
no sandbox needed in that case ^
[2:18]
anyways I’ll draw some pictures
[2:19]
the interface is sick, and it does what I need!
[2:19]
functionality isn’t whats got me hung up, security and portability is
@ryan [2:24 AM]
ok pictures are good
@atd [2:32 AM]
uploaded this image: Image uploaded from iOS
@atd [2:33 AM]
so this is how trezor provides multi browser support on Mac
@atd [2:37 AM]
uploaded this image: Image uploaded from iOS
@atd [2:37 AM]
that is trezor with just the chrome ext
[2:37]
gotta take dogs out
[2:37]
but I’ll show you what the password manager looks like in both scenarios
[2:37]
then the same scenarios on qubes
[2:38]
then what 21 looks like
[2:39]
@muneeb: would you like me to draw zerotier while I’m in an artsy mood?
patrick [2:40 AM]
muneeb may be in transit
@atd [2:40 AM]
Ah
@atd [3:01 AM]
uploaded this image: Image uploaded from iOS
@atd [3:02 AM]
two macs (p2p) connecting via zt w/o the need of the zt root server, both using chrome and trezors
