1 |
W dniu pią, 22.09.2017 o godzinie 20∶31 +0200, użytkownik Alexis Ballier |
2 |
napisał: |
3 |
> On Fri, 22 Sep 2017 19:39:16 +0200 |
4 |
> Michał Górny <mgorny@g.o> wrote: |
5 |
> |
6 |
> > W dniu pią, 22.09.2017 o godzinie 19∶15 +0200, użytkownik Alexis |
7 |
> > Ballier napisał: |
8 |
> > > On Fri, 22 Sep 2017 17:20:23 +0200 |
9 |
> > > Michał Górny <mgorny@g.o> wrote: |
10 |
> > > |
11 |
> > > > W dniu pią, 22.09.2017 o godzinie 12∶57 +0200, użytkownik Alexis |
12 |
> > > > Ballier napisał: |
13 |
> > > > > On Fri, 22 Sep 2017 06:07:18 +0200 |
14 |
> > > > > Michał Górny <mgorny@g.o> wrote: |
15 |
> > > > > |
16 |
> > > > > > W dniu czw, 21.09.2017 o godzinie 15∶41 -0700, użytkownik Matt |
17 |
> > > > > > Turner napisał: |
18 |
> > > > > > > On Thu, Sep 21, 2017 at 2:25 PM, Michał Górny |
19 |
> > > > > > > <mgorny@g.o> wrote: |
20 |
> > > > > > > > Given that sandbox is utterly broken by design, I don't |
21 |
> > > > > > > > really want to put too much effort in trying to make it a |
22 |
> > > > > > > > little better. I'd rather put the minimal effort required |
23 |
> > > > > > > > to make it not-much-worse. |
24 |
> > > > > > > |
25 |
> > > > > > > You said in your initial email that you weren't an expert |
26 |
> > > > > > > in its internals, but here you say it's broken by design. |
27 |
> > > > > > > Why do you think that? |
28 |
> > > > > > > |
29 |
> > > > > > |
30 |
> > > > > > Because it uses LD_PRELOAD which is a huge hack and which |
31 |
> > > > > > causes guaranteed issues we can't really fix. All we can do |
32 |
> > > > > > is disable it for emacs, for compiler-rt and I'm afraid this |
33 |
> > > > > > list will grow because overriding random library functions is |
34 |
> > > > > > never a good idea. |
35 |
> > > > > |
36 |
> > > > > I think we're all ears for a better solution. There are probably |
37 |
> > > > > much better ways to do sandboxing these days than 15 years ago. |
38 |
> > > > > |
39 |
> > > > > LD_PRELOAD does not work with static binaries. Hence the non |
40 |
> > > > > portable ptrace stuff. Hence bugs. Etc. The point is, that's the |
41 |
> > > > > best we have now. |
42 |
> > > > > |
43 |
> > > > |
44 |
> > > > I know of two obvious alternatives: ptrace and filesystem layer |
45 |
> > > > (e.g. FUSE). |
46 |
> > > > |
47 |
> > > > For the former, there's sydbox. I'm going to look into |
48 |
> > > > integrating it into Portage when I have more time. |
49 |
> > > |
50 |
> > > From: https://github.com/alip/pinktrace/blob/master/configure.ac |
51 |
> > > case "$host_cpu" in |
52 |
> > > i[[3456]]86|pentium) |
53 |
> > > x86?64*|amd64) |
54 |
> > > ia64) |
55 |
> > > powerpc64*) |
56 |
> > > powerpc*) |
57 |
> > > arm*) |
58 |
> > > [add support for those arches] |
59 |
> > > *) |
60 |
> > > AC_MSG_RESULT([NO!]) |
61 |
> > > AC_MSG_ERROR([Architecture $host_cpu is not supported by |
62 |
> > > pinktrace]) ;; |
63 |
> > > |
64 |
> > > sandbox keywords: |
65 |
> > > 2.11-r5:0: ~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc |
66 |
> > > ~ppc64 ~s390 ~sh ~sparc ~sparc-fbsd ~x86 ~x86-fbsd |
67 |
> > > |
68 |
> > > |
69 |
> > > Good luck adding the missing bits! |
70 |
> > > |
71 |
> > > |
72 |
> > > > For the latter, I have writing one in TODO. But I'm not sure when |
73 |
> > > > I'll have enough time to do work on it. |
74 |
> > > |
75 |
> > > Not sure how that would work, but you'll likely need some kind of |
76 |
> > > chroot/container since you don't want to trust a random binary ran |
77 |
> > > as root to respect environment variables. |
78 |
> > > |
79 |
> > |
80 |
> > Environment variables? What for? |
81 |
> > |
82 |
> |
83 |
> I don't know :) |
84 |
> I have no idea how you would provide a virtual FS that would be the |
85 |
> only thing ever seen by all processes spawned. |
86 |
> |
87 |
|
88 |
Using chroot(), obviously. |
89 |
|
90 |
-- |
91 |
Best regards, |
92 |
Michał Górny |