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
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <rmeijer@xs4all.nl>) id 1TtM89-00022g-R5
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Jan 2013 17:41:29 +0000
X-ACL-Warn:
Received: from smtp-vbr6.xs4all.nl ([194.109.24.26])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1TtM87-0000Qp-G5 for bitcoin-development@lists.sourceforge.net;
Thu, 10 Jan 2013 17:41:29 +0000
Received: from webmail.xs4all.nl (dovemail16.xs4all.nl [194.109.26.18])
by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id r0AHfLW1011848;
Thu, 10 Jan 2013 18:41:21 +0100 (CET)
(envelope-from rmeijer@xs4all.nl)
Received: from 83.163.132.66 (SquirrelMail authenticated user rmeijer)
by webmail.xs4all.nl with HTTP; Thu, 10 Jan 2013 18:41:21 +0100
Message-ID: <e1e8f72a8638b34aa5513dd2f2b05dab.squirrel@webmail.xs4all.nl>
In-Reply-To: <4aa4401704cc1e7a1665971b79684a83.squirrel@webmail.xs4all.nl>
References: <4aa4401704cc1e7a1665971b79684a83.squirrel@webmail.xs4all.nl>
Date: Thu, 10 Jan 2013 18:41:21 +0100
From: "Rob Meijer" <rmeijer@xs4all.nl>
To: rmeijer@xs4all.nl
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.0 (/)
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.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1TtM87-0000Qp-G5
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [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: Thu, 10 Jan 2013 17:41:30 -0000
My efforts on MinorFs2 have been stalled for a large period of time
(resulting from the fact that I was writing it in Python and Google
pulling the plug on its codesearch server showed me that Python was a
language that I hadn't sufficiently mastered. Recently, after almost a
year of reluctance at starting from scratch, I finaly set myself to
rewriting what I had done so far in C++ and to continue development.
Yesterday I've also started at a library for making the usage of MinorFs
by applications like Bitcoin more convenient. The idea is that LibMinorFs
will become a simple to use library for making applications
MinorFs2-aware.
I would like to ask if the bitcoin developers would be open to using
this library within bitcoin for making BitCoin MinorFs2 aware, allowing it
to store things like the BitCoin purse in a private directory that is not
available to other unrelated (potentially trojan) processes running under
the same uid.
The API is defined in the inc/minorfs/ directory and the usage shown in
src/testmain.cpp
https://github.com/pibara/LibMinorFs2
Both the library and the filesystems are still far from being done, but I
would like to know if you guys would be open to a pull-request that would
incorporate a copy of this library into Bitcoin, making BitCoin use
private storage when available, implemented using the above API.
Please let me know what you think.
Rob
On Fri, August 26, 2011 08:48, Rob Meijer wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
|
