GNU bug report logs - #43770
Geeks think securely: VM per Package (trustless state to devs and their apps)

Previous Next

Full log

View this message in rfc822 format

From: raingloom <raingloom <at> riseup.net>
To: 43770 <at> debbugs.gnu.org
Subject: bug#43770: Geeks think securely: VM per Package (trustless state to devs and their apps)
Date: Fri, 2 Oct 2020 21:45:14 +0200

On Fri, 2 Oct 2020 18:01:18 +0000
bo0od <bo0od <at> riseup.net> wrote:

> Hi There,
> 
> If we look at current state of packages running inside GNU distros
> they are in very insecure shape which is either they are installed
> without sandboxing because the distro doesnt even provide that or no
> profiles exist for the sandboxing feature and has issues e.g:
> 
> - Sandboxing can be made through MAC (apparmor,selinux) or Using 
> Namespaces (firejail,bubblewrap) But the problem with using these 
> features it needs a defined/preconfigured profile for each package in 
> order to use them thus making almost impossible case to be applied on 
> every package in real bases. (unless a policy which saying no package
> is allowed without coming with its own MAC profile, but thats as well
> has another issue when using third party packages...)
> 
> - Containers are like OS, and to use it within another OS is like OS
> in OS i find it crazy and not just that the way that the package gets 
> upgraded is not reliable to be secure so this wont solve our issue as
> well.
> 
> To solve this mess, is to use virtualization method and to make that 
> happen is to put each package in a VM by itself means the package
> gonna use the system resources without being able maliciously gain 
> anything.This provide less trust to developers and their code running 
> within the system.
> 
> one of the greatest design made in our time towards security is 
> GNU/Linux Qubes OS, it uses OS per VM and has VM to VM 
> communication...etc i highly recommend reading their design to take
> some ideas from it:
> 
> https://www.qubes-os.org/doc/

There is an even more relevant project being developed in NixOS, but I
can't remember its name off the top of my head.

My 2 cents is that I'd rather have the option to use packages that are
closer to Alpine than having to pay the performance penalty of Qubes.
Fewer lines of code => fewer bugs => fewer security holes.

> Useful refer:
> 
> https://wiki.debian.org/UntrustedDebs
> https://blog.invisiblethings.org/papers/2015/state_harmful.pdf
> 
> ThX!
> 
> 
> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.