[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Plan for Guix security (was Re: Long term plan for GuixSD security: micr
Plan for Guix security (was Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support)
Wed, 26 Dec 2018 05:56:15 +0800
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
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
For RISC-V, my dream would be using a RISC-V chip 3D-printed from a GPL
In addition, I have some other ideas regarding guix security.
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?
Description: PGP signature
- Plan for Guix security (was Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support),
Alex Vong <=