Plan for Guix security (was Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support)

[Alex Vong <alexvong1995@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

Hello everyone,


For microkernel, sel4 being a formally verified microkernel (developed
by security researchers?) looks promising to me. Maybe someday we can
rebase hurd on top of it (replacing mach)...

For ocap, I've no idea about it. I've heard of apparmor and selinux but
not ocap. Btw, debian has started shipping apparmor profiles since 2017
if I remember correctly. If everything's going well, it should be in the
next stable release. Should guix ship apparmor / selinux profiles as
well?

For RISC-V, my dream would be using a RISC-V chip 3D-printed from a GPL
design :)


In addition, I have some other ideas regarding guix security.

According to <https://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html>,
X server lacks GUI isolation. As a result, user gaining local acess to
the machine can run a keylogger logging sudo password. This nullifies
many security maeasures. Is guix vulnerable to this as well?

If so, how should we fix it? Qubes OS fixes it by virtualization
(running programs in a VM). But it seems to me that having multiple OS
complicates things. I haven't tried using Qubes OS though.

Besides, I remember we have discuss about hardening before. Should I
start a new hardening branch? (although I don't time to work on it right
now). I think this is something we can do now.

My idea is to create a new guix module (guix build hardening) which
should contains various build flags. Then we should modifiy each build
system to import from this new module and fix any build error caused by
it. We can ask the build farm to evaluate this new branch, right?


What do you think?

Cheers,
Alex

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]