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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <capibara@xs4all.nl>) id 1R0Y40-0001vz-NA
for bitcoin-development@lists.sourceforge.net;
Mon, 05 Sep 2011 12:14:08 +0000
X-ACL-Warn:
Received: from smtp-vbr13.xs4all.nl ([194.109.24.33])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1R0Y3w-0008Mb-M9 for bitcoin-development@lists.sourceforge.net;
Mon, 05 Sep 2011 12:14:08 +0000
Received: from webmail.xs4all.nl (dovemail18.xs4all.nl [194.109.26.20])
by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id p85CDr9j010797;
Mon, 5 Sep 2011 14:13:53 +0200 (CEST)
(envelope-from capibara@xs4all.nl)
Received: from 92.70.45.2 (SquirrelMail authenticated user rmeijer)
by webmail.xs4all.nl with HTTP; Mon, 5 Sep 2011 14:13:58 +0200
Message-ID: <93ffca16f2e9178f302e8b1c0dc52afe.squirrel@webmail.xs4all.nl>
In-Reply-To: <CAJNQ0stL3yP9mJtPMEjWZeHtKT-3kZ+Psbpfs1XtVnEnd6x2gQ@mail.gmail.com>
References: <4aa4401704cc1e7a1665971b79684a83.squirrel@webmail.xs4all.nl>
<d6060149473a3262940e624e13e6e061.squirrel@webmail.xs4all.nl>
<CAJNQ0stL3yP9mJtPMEjWZeHtKT-3kZ+Psbpfs1XtVnEnd6x2gQ@mail.gmail.com>
Date: Mon, 5 Sep 2011 14:13:58 +0200
From: "Rob Meijer" <capibara@xs4all.nl>
To: "John Smith" <witchspace81@gmail.com>
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.33 listed in list.dnswl.org]
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1R0Y3w-0008Mb-M9
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: Mon, 05 Sep 2011 12:14:08 -0000
On Sat, September 3, 2011 09:04, John Smith wrote:
> On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer <capibara@xs4all.nl> wrote:
>
>> Given that there was not a single response to my post, I gather there is
>> no to little interest in an updated MinorFs that could be used by
>> bitcoin
>> on systems that support AppArmor (Ubuntu and OpenSuse).
>>
>
> Oh yes there is interest. I meant to reply but haven't been able to put
> much
> energy in bitcoin development lately.
>
> More strict privilege seperation between applications on a least-authority
> basis is something that Ubuntu is certainly going to need if they're
> serious
> with the app store thing (and want to keep up with Android and Macosx...).
>
> This has been needed for a long time, and this would be useful for any
> private data managed by applications running as the same user (ssh,
> browsers, pgp, ...)
>
> Wallet encryption is useful and necessary but no substitute for OS-level
> protection.
>
>
>> Nevertheless I've put down the initial set of specs for a rewrite of
>> MinorFs for if anyone would like to comment on them to make a future
>> match
>> with Bitcoin more likely, I'm open to all sugestions:
>>
>> http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2
>>
>
> You have to rewrite the entire thing from scratch?
I think its best. The old version I wrote in Perl using some rather rarely
used perl modules from cpan that don't have packages in either opensuse
nor ubuntu. I've moved most of my other new development projects to Python
or C++ for a long time, so Python has become much more natural for me to
work in, while migrating all perl module usage to a packaging compatible
set would also be a pretty large task.
From this I concluded that it would probably be best to take lessons
learned from the existing MinorFs and do a rewrite in Python, making sure
all python modules used are available in both OpenSuse and ubuntu.
> This is probably blasphemy but: how can it be compared to the android
> model,
> with a UID per application/user, and thus layering the security on top of
> current UNIX/ACL permissions? Is another FS really needed?
MinorFs IS basically a set of user space file-systems on top of current
UNIX/ACL permissions. Without further changes with application granularity
and without delegation of sub-trees, the two are basically equivalent.
The plans I currently have will allow a migration path from such a model
to one with a finer granularity level where sub systems delegate sub trees
to eachother in a pass by reference way.
> JS
>
|
