From: raingloom <raingloom@riseup.net>
To: 43770@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 [thread overview]
Message-ID: <20201002214514.168ee5e1@riseup.net> (raw)
In-Reply-To: <0adb9d2b-22e6-412d-4148-fd032d191b6b@riseup.net>
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!
>
>
>
prev parent reply other threads:[~2020-10-02 19:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 18:01 bug#43770: Geeks think securely: VM per Package (trustless state to devs and their apps) bo0od
2020-10-02 19:44 ` Ricardo Wurmus
2020-10-02 22:18 ` bo0od
2020-10-05 14:00 ` Ludovic Courtès
2020-10-02 19:45 ` raingloom [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201002214514.168ee5e1@riseup.net \
--to=raingloom@riseup.net \
--cc=43770@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.