ocap discipline by example Re: ZeroVault
14 views
Skip to first unread message
Dan Connolly
Nov 22, 2016, 6:04:22 PM11/22/16
to cap-...@googlegroups.com
On Wed, Nov 16, 2016 at 2:53 AM, Rob Meijer <pib...@gmail.com> wrote:
> https://github.com/pibara/ZeroVault
>
> Any feedback or pull requests are very much welcomed.
I was interested to know whether ZeroVault stores any state
server-side or sends any sensitive info over the network. Turns out it
does (in contrast to supergenpass). Fair enough.
But it wasn't obvious from a quick inspection of the index.cgi python script.
So as is my habit[1], I refactored the code to use ocap discipline:
https://github.com/pibara/ZeroVault/pull/1 c1bc90f ... 8912804
The result isn't as nice as I'd like... I could perhaps make the flow
of authority more clear by integrating the FileSystemLoader with the
Path object. And factoring out the handling of untrusted input in a
function that main() calls with attenuated capabilities would probably
reduce risk by a bit. But what I have proposed meets a minimal
threshold: no ambient authority is available at the module scope. The
usual benefits follow: main() is unit-testable.
I started on a similar effort for the cloudabi build scrips. That one
is a couple orders of magnitude more work and I haven't finished it.
https://github.com/NuxiNL/cloudabi-ports/pull/24 0ba583598048
The cloudabi security model doesn't directly depend on ocap discipline
in the the build scripts. And there probably weren't any critical
security flaws in the 80 lines of index.cgi. But ocap discipline is
just good engineering practice, right? It's a best practice we should
use out of habit.
I'd like to see more leading by examples with ocap discipline, even
when the platform is something like python where the language doesn't
have strong ocap guarantees.
The sandstorm shell is written in javascript where strong ocap
guarantees are feasible. But the shell is a meteor app. Meteor is
structured around global state, so ocap discipline is out the window.
The emphasis on meteor in sandstorm grates on me.
https://sandstorm.io/news/2014-08-12-meteor-spk
[1] http://www.madmode.com/2013/python-capability-idioms-part-1.html
--
Dan Connolly
http://www.madmode.com/
> https://github.com/pibara/ZeroVault
>
> Any feedback or pull requests are very much welcomed.
I was interested to know whether ZeroVault stores any state
server-side or sends any sensitive info over the network. Turns out it
does (in contrast to supergenpass). Fair enough.
But it wasn't obvious from a quick inspection of the index.cgi python script.
So as is my habit[1], I refactored the code to use ocap discipline:
https://github.com/pibara/ZeroVault/pull/1 c1bc90f ... 8912804
The result isn't as nice as I'd like... I could perhaps make the flow
of authority more clear by integrating the FileSystemLoader with the
Path object. And factoring out the handling of untrusted input in a
function that main() calls with attenuated capabilities would probably
reduce risk by a bit. But what I have proposed meets a minimal
threshold: no ambient authority is available at the module scope. The
usual benefits follow: main() is unit-testable.
I started on a similar effort for the cloudabi build scrips. That one
is a couple orders of magnitude more work and I haven't finished it.
https://github.com/NuxiNL/cloudabi-ports/pull/24 0ba583598048
The cloudabi security model doesn't directly depend on ocap discipline
in the the build scripts. And there probably weren't any critical
security flaws in the 80 lines of index.cgi. But ocap discipline is
just good engineering practice, right? It's a best practice we should
use out of habit.
I'd like to see more leading by examples with ocap discipline, even
when the platform is something like python where the language doesn't
have strong ocap guarantees.
The sandstorm shell is written in javascript where strong ocap
guarantees are feasible. But the shell is a meteor app. Meteor is
structured around global state, so ocap discipline is out the window.
The emphasis on meteor in sandstorm grates on me.
https://sandstorm.io/news/2014-08-12-meteor-spk
[1] http://www.madmode.com/2013/python-capability-idioms-part-1.html
--
Dan Connolly
http://www.madmode.com/
Rob Meijer
Nov 23, 2016, 7:18:10 AM11/23/16
to cap-talk
On Wed, Nov 16, 2016 at 2:53 AM, Rob Meijer <pib...@gmail.com> wrote:
> https://github.com/pibara/ZeroVault
>
> Any feedback or pull requests are very much welcomed.
I was interested to know whether ZeroVault stores any state
server-side or sends any sensitive info over the network. Turns out it
does (in contrast to supergenpass). Fair enough.
There are two things that are transferred over the network:
- The seed cookie that is derived from the server salt and the seed passphrase. This is meant as a way to synchonize different browsers and to allow for somewhat weaker generator passphrases.
- Revocation tokens for individual generated passwords.
The state stored on the server is a list of revocation tokens. The below diagram gives a bit of a base outline:
- The server salt is combined with a seed passphrase (entered on first use from a browser) into a seed cookie. This seed cookie is to be the same on each browser you use to access ZeroVault.
- The seed cookie combined with the server salt generates a revocation tokens filename. If this file exists it contains a list of revocation tokens.
- A web page is generated containing both the seed cookie info and the revocation token list from the revocation list file on the server.
- A generator passphrase, the web server domain and the username are used with the seed cookie to generate a 32 byte pass key candidate.
- A static string combined with the pass key candidate is used to generate a revocation token.
- If the revocation token is found in the revocation token list, then the password candidate is used in place of the seed cookie and things are repeated from two steps back and down for as many times until no matching revocation key is found.
- In case of incidence response, the revocation key for the currently valid pass key candidate can be uploaded to the server and added to the revocation key set file.
Hope this makes sense and explains how and why of the server side state and server <->client token exchange.
Rob Meijer
Nov 23, 2016, 7:25:19 AM11/23/16
to cap-talk
On Wednesday, 23 November 2016 13:18:10 UTC+1, Rob Meijer wrote:
On Wednesday, 23 November 2016 00:04:22 UTC+1, Dan Connolly wrote:
On Wed, Nov 16, 2016 at 2:53 AM, Rob Meijer <pib...@gmail.com> wrote:
> https://github.com/pibara/ZeroVault
>
> Any feedback or pull requests are very much welcomed.
I was interested to know whether ZeroVault stores any state
server-side or sends any sensitive info over the network. Turns out it
does (in contrast to supergenpass). Fair enough.There are two things that are transferred over the network:
- The seed cookie that is derived from the server salt and the seed passphrase. This is meant as a way to synchonize different browsers and to allow for somewhat weaker generator passphrases.
- Revocation tokens for individual generated passwords.
The state stored on the server is a list of revocation tokens. The below diagram gives a bit of a base outline:
Oops, messed up the loop revocation loop:
Rob Meijer
Nov 23, 2016, 7:37:19 AM11/23/16
to cap-talk
On Wednesday, 23 November 2016 00:04:22 UTC+1, Dan Connolly wrote:
So as is my habit[1], I refactored the code to use ocap discipline:
https://github.com/pibara/ZeroVault/pull/1 c1bc90f ... 8912804
Though I never considered such for Python due to its type system, I make it a habbit to use a type
of ocap dicipline for 'resource' coding in C++ in order to avoid singleton nightmares.
Seems like good practice though to aim for similar style elements in non capability secure languages
even without a type system to help out. Tnx.
Reply all
Reply to author
Forward
0 new messages