Geeks think securely: VM per Package (trustless state to devs and their apps)

  • Done
  • quality assurance status badge
Details
4 participants
  • bo0od
  • Ludovic Courtès
  • raingloom
  • Ricardo Wurmus
Owner
unassigned
Submitted by
bo0od
Severity
normal

Debbugs page

bo0od wrote 4 years ago
(address . bug-guix@gnu.org)
0adb9d2b-22e6-412d-4148-fd032d191b6b@riseup.net
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:


Useful refer:


ThX!
Ricardo Wurmus wrote 4 years ago
(name . bo0od)(address . bo0od@riseup.net)(address . 43770@debbugs.gnu.org)
87mu14e7k5.fsf@elephly.net
Hi,

this does not look like an actionable bug report. What is it exactly
that ought to be done in your opinion?

--
Ricardo
raingloom wrote 4 years ago
(address . bug-guix@gnu.org)
20201002214514.168ee5e1@riseup.net
On Fri, 2 Oct 2020 18:01:18 +0000
bo0od <bo0od@riseup.net> wrote:

Toggle quote (33 lines)
> 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.

Toggle quote (9 lines)
> Useful refer:
>
> https://wiki.debian.org/UntrustedDebs
> https://blog.invisiblethings.org/papers/2015/state_harmful.pdf
>
> ThX!
>
>
>
bo0od wrote 4 years ago
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 43770@debbugs.gnu.org)
c561674e-ef70-d36f-c991-f89a18d2d656@riseup.net
Hey,

Actually what i wanted to say but seems i missed it, This security
design can be engineered and implemented when Guixsd released based on
GNU-Hurd Kernel. Because its going to be totally new kernel and having
this feature is without question the best security feature for the
future of security within operating systems.

Otherwise we gonna fall into the same cycle of trust to outside package
developers and their codes without preventive mechanism against if its
malicious one.

If you mean the bug report is not the place for this request, then i
dont know where because i already discussed it in the IRC channel.(if
there is somewhere else i can report this just tell me)

ThX!

Ricardo Wurmus:
Toggle quote (6 lines)
>
> Hi,
>
> this does not look like an actionable bug report. What is it exactly
> that ought to be done in your opinion?
>
Ludovic Courtès wrote 4 years ago
(name . bo0od)(address . bo0od@riseup.net)(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 43770-done@debbugs.gnu.org)
87zh50wz54.fsf@gnu.org
Hi,

bo0od <bo0od@riseup.net> skribis:

Toggle quote (14 lines)
> Actually what i wanted to say but seems i missed it, This security
> design can be engineered and implemented when Guixsd released based on
> GNU-Hurd Kernel. Because its going to be totally new kernel and having
> this feature is without question the best security feature for the
> future of security within operating systems.
>
> Otherwise we gonna fall into the same cycle of trust to outside
> package developers and their codes without preventive mechanism
> against if its malicious one.
>
> If you mean the bug report is not the place for this request, then i
> dont know where because i already discussed it in the IRC channel.(if
> there is somewhere else i can report this just tell me)

It’s great to share your views of what you think should be done from a
security standpoint. There’s little more we contributors can say other
than: yes, we agree, we’re working in this direction, and it’s going to
be a long journey.

What could help though is if people like you come and join us on that
journey. I very much encourage you to play with Guix System and in
particular with the “childhurd” service that has recently landed and
should be of interest to you.

For now I’m closing the bug because as Ricardo wrote, it’s not a bug
report per se.

Thank you,
Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 43770@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 43770
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help