1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <capibara@xs4all.nl>) id 1Qwr9d-0008VZ-Li
for bitcoin-development@lists.sourceforge.net;
Fri, 26 Aug 2011 07:48:41 +0000
X-ACL-Warn:
Received: from smtp-vbr6.xs4all.nl ([194.109.24.26])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Qwr9Y-0006Zu-KN for bitcoin-development@lists.sourceforge.net;
Fri, 26 Aug 2011 07:48:41 +0000
Received: from webmail.xs4all.nl (dovemail12.xs4all.nl [194.109.26.14])
by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id p7Q7mNUE093051
for <bitcoin-development@lists.sourceforge.net>;
Fri, 26 Aug 2011 09:48:28 +0200 (CEST)
(envelope-from capibara@xs4all.nl)
Received: from 83.163.132.66 (SquirrelMail authenticated user rmeijer)
by webmail.xs4all.nl with HTTP; Fri, 26 Aug 2011 09:48:28 +0200
Message-ID: <4aa4401704cc1e7a1665971b79684a83.squirrel@webmail.xs4all.nl>
Date: Fri, 26 Aug 2011 09:48:28 +0200
From: "Rob Meijer" <capibara@xs4all.nl>
To: bitcoin-development@lists.sourceforge.net
User-Agent: SquirrelMail/1.4.18
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [194.109.24.26 listed in list.dnswl.org]
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1Qwr9Y-0006Zu-KN
Subject: [Bitcoin-development] BitCoin and MinorFs/AppArmor
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: rmeijer@xs4all.nl
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 26 Aug 2011 07:48:41 -0000
A few years ago I wrote a least authority based set of filesystems named
MinorFs that worked closely together with AppArmor (suse/ubuntu) to give '
pseudo persistent processes' their own private but decomposable and
delegatable piece of filesystem storage:
http://www.linuxjournal.com/magazine/minorfs
http://www.capibara.com/blog/2011/05/25/taming-mutable-state-for-file-systems/
Currently there is only one perfect fit for MinorFs and that's the stack
AppArmor/MinorFs/E-language-persistent-application. There are some close
fits like running ssh without a passphrase (
http://minorfs.polacanthus.net/wiki/Ssh_private_keys_without_passphrase )
but these require lots of manual fiddling by the user to get working. The
ssh trick would probably work with bitcoin, but as you can see from the
link above, it would be rather cumbersome.
I am trying to get specs together for rewriting MinorFs (in Python) in a
way that would make it easy and natural for application developers that
want their application to be able to protect user data (like bitcoin
wallets) from mallware running under the same uid as that user.
Currently minorfs granularity is hard fixed to that of the 'pseudo
persistent process', and that granularity is determined as described in
the following link:
http://minorfs.polacanthus.net/wiki/Pseudo_persistent_process
When using pseudo persistent processes, you basically end up with
file-system storage that follows almost all of the modeling principles of
the object capability model. This is great when designing a least
authority program from scratch and writing it in the (object capability)
e-language using its persistence facilities.
Given however that I don't expect bitcoin, openssh, chrome, firefox, or
any other application that would benefit from what MinorFs provides to be
rewritten in E, it seems like the next version of MinorFs should give up
on the purity of its least authority model, and take an approach that
better suits common development languages and practices.
With bitcoin being a project that could benefit most from what MinorFs has
to offer, I would like to ask bitcoin developers to think about what
attributes from the current granularity level (pseudo persistent process)
should be kept, what attributes should be dropped, and what properties
should be added to arrive at an 'id' that is the best fit for granularity
of persistent private storage for bitcoin.
I really want to accommodate bitcoin developer needs in this, so all input
that helps me help you guys to get the next MinorFs version to accommodate
your needs to a level that code to use MinorFs where available can be
added to bitcoin, would be extremely welcome.
Let me know what you think,
Rob
|
