Re: [gentoo-dev] Reviving the Sandbox project

["Michał Górny" <mgorny@gentoo.org>]

W dniu pią, 22.09.2017 o godzinie 20∶31 +0200, użytkownik Alexis Ballier
napisał:
> On Fri, 22 Sep 2017 19:39:16 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > W dniu pią, 22.09.2017 o godzinie 19∶15 +0200, użytkownik Alexis
> > Ballier napisał:
> > > On Fri, 22 Sep 2017 17:20:23 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > >   
> > > > W dniu pią, 22.09.2017 o godzinie 12∶57 +0200, użytkownik Alexis
> > > > Ballier napisał:  
> > > > > On Fri, 22 Sep 2017 06:07:18 +0200
> > > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > >     
> > > > > > W dniu czw, 21.09.2017 o godzinie 15∶41 -0700, użytkownik Matt
> > > > > > Turner napisał:    
> > > > > > > On Thu, Sep 21, 2017 at 2:25 PM, Michał Górny
> > > > > > > <mgorny@gentoo.org> wrote:      
> > > > > > > > Given that sandbox is utterly broken by design, I don't
> > > > > > > > really want to put too much effort in trying to make it a
> > > > > > > > little better. I'd rather put the minimal effort required
> > > > > > > > to make it not-much-worse.      
> > > > > > > 
> > > > > > > You said in your initial email that you weren't an expert
> > > > > > > in its internals, but here you say it's broken by design.
> > > > > > > Why do you think that?
> > > > > > >       
> > > > > > 
> > > > > > Because it uses LD_PRELOAD which is a huge hack and which
> > > > > > causes guaranteed issues we can't really fix. All we can do
> > > > > > is disable it for emacs, for compiler-rt and I'm afraid this
> > > > > > list will grow because overriding random library functions is
> > > > > > never a good idea. 
> > > > > 
> > > > > I think we're all ears for a better solution. There are probably
> > > > > much better ways to do sandboxing these days than 15 years ago.
> > > > > 
> > > > > LD_PRELOAD does not work with static binaries. Hence the non
> > > > > portable ptrace stuff. Hence bugs. Etc. The point is, that's the
> > > > > best we have now.
> > > > >     
> > > > 
> > > > I know of two obvious alternatives: ptrace and filesystem layer
> > > > (e.g. FUSE).
> > > > 
> > > > For the former, there's sydbox. I'm going to look into
> > > > integrating it into Portage when I have more time.  
> > > 
> > > From: https://github.com/alip/pinktrace/blob/master/configure.ac
> > > case "$host_cpu" in
> > > i[[3456]]86|pentium)
> > > x86?64*|amd64)
> > > ia64)
> > > powerpc64*)
> > > powerpc*)
> > > arm*)
> > >  [add support for those arches]
> > > *)
> > > 	AC_MSG_RESULT([NO!])
> > > 	AC_MSG_ERROR([Architecture $host_cpu is not supported by
> > > pinktrace]) ;;
> > > 
> > > sandbox keywords:
> > > 2.11-r5:0: ~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc
> > >  ~ppc64 ~s390 ~sh ~sparc ~sparc-fbsd ~x86 ~x86-fbsd
> > > 
> > > 
> > > Good luck adding the missing bits!
> > > 
> > >   
> > > > For the latter, I have writing one in TODO. But I'm not sure when
> > > > I'll have enough time to do work on it.  
> > > 
> > > Not sure how that would work, but you'll likely need some kind of
> > > chroot/container since you don't want to trust a random binary ran
> > > as root to respect environment variables.
> > >   
> > 
> > Environment variables? What for?
> > 
> 
> I don't know :)
> I have no idea how you would provide a virtual FS that would be the
> only thing ever seen by all processes spawned.
> 

Using chroot(), obviously.

-- 
Best regards,
Michał Górny