[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43770: Geeks think securely: VM per Package (trustless state to devs
From: |
raingloom |
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@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!
>
>
>