Long term plan for GuixSD security: microkernels, ocap, RISC-V support

Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Christopher Lemmer Webber]

Hello... reading over a few articles this morning:

 - Researchers Blame ‘Monolithic’ Linux Code Base for Critical
   Vulnerabilities
   https://threatpost.com/researchers-blame-monolithic-linux-code-base-for-critical-vulnerabilities/136785/
 - Its associated paper:
   "The Jury Is In: Monolithic OS Design Is Flawed"
   http://ts.data61.csiro.au/publications/csiro_full_text/Biggs_LH_18.pdf
 - Brains behind seL4 secure microkernel begin RISC-V chip port
   https://www.theregister.co.uk/2018/04/23/risc_v_sel4_port/

I'm bringing this up because I want to plant the seed for some thinking
and conversation:

 - It's getting hard to trust our computers as in terms of our physical
   hardware.  Companies like Purism are helping to build blobless
   systems, but even then the hardware is built on un-auditable and
   with growing apparent insecurity (Spectre, Meltdown) with little
   chance of fixing things.  RISC-V has a libre instruction set, and in
   the long term I think we want to support that.

 - In terms of software, currently we run on ACL-heavy systems, which
   are well known to be insecure designs:
     http://waterken.sourceforge.net/aclsdont/current.pdf
   If a computer program behaves badly, it shouldn't be able to do any
   more damage than the smallest amount of authority it should need to
   run.  Currently programs run with the full authority of the user.
   This means that a tiny code flaw in even the most trivial package
   can lead to complete user compromise.

   In the long run, we'll want to support object capability based OS
   designs which follow the principle of least authority, so a program's
   vulnerabilities will be limited in scope.

 - What paths do we have forward on that last one?

   - Well, GNU Hurd is a microkernel + ocap system (while also trying
     to be POSIX compatible).  Manolis has done much good work in
     helping to make that a more feasible option for Guix users.

   - There's also seL4 which has a verified security kernel, possibly
     even seL4 with Genode.  I'm not sure how hard it will be to run
     POSIX type things on Genode.

   - There's also Google's recent work with Magenta/Fuschia.  From what
     I've read, architecturally this looks right.  I think the reason
     for worry here is the same difficulty the community has had to
     build actual community and libre distributions on top of the
     Android ecosystem could apply here.

 - It's also worth noting that the most common class of serious
   application / library vulnerabilities that we have to deal with is C
   / C++ memory management issues.  I'm not saying we should embrace
   everything getting ported to Rust, but I do think it's important to
   note that we're finally seeing paths out of that nightmare.

As a side note, if we don't have both together (libre hardware + ocap)
and we just have microkernel + ocap systems on top of proprietary
hardware, especially heavily "vendor controlled" systems, we could end
up much more screwed than we are even in our current systems, which is
why I think it's critical that we engage these things.  In the book
Rainbow's End (minor spoilers here) it's hinted that all the users are
running computers which have object capaiblity security and are thus
much more resilient to attacks, except that the bottom most layer of the
system is intentionally government compromised so that all systems are
effectively backdoored.  So, your sustem is secure... except for the
backdoor.

Anyway... the goal of this email was mostly just to try to get people
thinking about the direction we want to go long term.  Hope that's
useful/interesting even if it isn't an actual contribution of code
towards it ;)

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Ricardo Wurmus]

Hey,

>  - In terms of software, currently we run on ACL-heavy systems, which
>    are well known to be insecure designs:
>      http://waterken.sourceforge.net/aclsdont/current.pdf
>    If a computer program behaves badly, it shouldn't be able to do any
>    more damage than the smallest amount of authority it should need to
>    run.  Currently programs run with the full authority of the user.
>    This means that a tiny code flaw in even the most trivial package
>    can lead to complete user compromise.
>
>    In the long run, we'll want to support object capability based OS
>    designs which follow the principle of least authority, so a program's
>    vulnerabilities will be limited in scope.

I agree, which is why I think that in the short term we should look into
doing more work on SELinux policies (hear me out, please).  SELinux
already exists and it provides an implementation of mandatory access
control.  The big picture idea is: processes and files are assigned to
certain domains where only certain access types are permitted and the
kernel enforces these declarations.  Processes can transition from one
domain to another only according to policies.

SELinux certainly isn’t pretty, but it isn’t quite as complicated as the
bad documentation out there makes it seem.

I was thinking that we could have an internship (GSoC or Outreachy)
project to implement support for SELinux in Guix, including the design
of an extensible policy scheme.  I think Guix is uniquely suited as the
foundation of an understandable SELinux system.  (Think of how the
existing system service framework could be extended to provide
context-specific SELinux policies.)

>    - Well, GNU Hurd is a microkernel + ocap system (while also trying
>      to be POSIX compatible).  Manolis has done much good work in
>      helping to make that a more feasible option for Guix users.

I’d love to get us closer to being able to run the GNU system with the
Hurd and Guix underpinnings.  Unfortunately, Hurd is not considered a
priority by GNU, which shows in the lack of support for modern hardware.

> As a side note, if we don't have both together (libre hardware + ocap)
> and we just have microkernel + ocap systems on top of proprietary
> hardware, especially heavily "vendor controlled" systems, we could end
> up much more screwed than we are even in our current systems, which is
> why I think it's critical that we engage these things.

I don’t understand this.  Why would the situation with microkernel +
ocap on top of proprietary hardware be *worse* than the current
situation of a monolithic ACL-based system on top of equally proprietary
hardware?

> In the book
> Rainbow's End (minor spoilers here) it's hinted that all the users are
> running computers which have object capaiblity security and are thus
> much more resilient to attacks, except that the bottom most layer of the
> system is intentionally government compromised so that all systems are
> effectively backdoored.  So, your sustem is secure... except for the
> backdoor.

… and *that* sounds like NSA’s SELinux again ;)

Seriously, though, I’m not saying we should “simply” use SELinux to
address this problem, but I think it can be one of the first stops on
our road to better systems.

> Anyway... the goal of this email was mostly just to try to get people
> thinking about the direction we want to go long term.  Hope that's
> useful/interesting even if it isn't an actual contribution of code
> towards it ;)

Code is often overrated.  I find it very important to discuss our
visions of the future to know in what direction we have to move and how
much effort we should make to get there in time.

--
Ricardo

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Christopher Lemmer Webber]

First off, I should mention that rain1 reminded me about OpenBSD's
Capsicum and the Capsicum for Linux project, which I had mostly
forgotten about:
  http://www.capsicum-linux.org/

Capsicum brings file descriptor based capabilities, and this is a
reasonable intermediate approach.

Shill is an ocap (object capability) supporting shell using Capsicum:
  http://shill.seas.harvard.edu/

Ricardo Wurmus writes:

> Hey,
>
>>  - In terms of software, currently we run on ACL-heavy systems, which
>>    are well known to be insecure designs:
>>      http://waterken.sourceforge.net/aclsdont/current.pdf
>>    If a computer program behaves badly, it shouldn't be able to do any
>>    more damage than the smallest amount of authority it should need to
>>    run.  Currently programs run with the full authority of the user.
>>    This means that a tiny code flaw in even the most trivial package
>>    can lead to complete user compromise.
>>
>>    In the long run, we'll want to support object capability based OS
>>    designs which follow the principle of least authority, so a program's
>>    vulnerabilities will be limited in scope.
>
> I agree, which is why I think that in the short term we should look into
> doing more work on SELinux policies (hear me out, please).  SELinux
> already exists and it provides an implementation of mandatory access
> control.  The big picture idea is: processes and files are assigned to
> certain domains where only certain access types are permitted and the
> kernel enforces these declarations.  Processes can transition from one
> domain to another only according to policies.
>
> SELinux certainly isn’t pretty, but it isn’t quite as complicated as the
> bad documentation out there makes it seem.
>
> I was thinking that we could have an internship (GSoC or Outreachy)
> project to implement support for SELinux in Guix, including the design
> of an extensible policy scheme.  I think Guix is uniquely suited as the
> foundation of an understandable SELinux system.  (Think of how the
> existing system service framework could be extended to provide
> context-specific SELinux policies.)

I'm not a big fan of SELinux because it's using an RBAC style system,
which is like a more fine grained ACL.  It's still a centralized
authority model, non-composable, and isn't as secure as a capability
security type approach.

I said this on IRC but:

<dustyweb> E in a Walnut has something to say about that
<dustyweb> > With tools like access control lists and firewalls, we engage in
           "perimeter defense", which is more correctly described as "eggshell
           defense". It is like an eggshell for the following reason: while an
           eggshell may seem pretty tough when you tap on it, if you can get a
           single pinhole anywhere in the surface, you can suck out the entire
           yoke.

Source: http://www.skyhunter.com/marcs/ewalnut.html

My personal view is that ACL'ish / RBAC'ish systems are the wrong
approach.  I suppose if someone wants to put effort into this direction
I don't object, unless it starts to complicate our tooling.  But for
focusing our efforts what I think we should do is work towards a better
long-term security approach of supporting object capability operating
system ideas.

>>    - Well, GNU Hurd is a microkernel + ocap system (while also trying
>>      to be POSIX compatible).  Manolis has done much good work in
>>      helping to make that a more feasible option for Guix users.
>
> I’d love to get us closer to being able to run the GNU system with the
> Hurd and Guix underpinnings.  Unfortunately, Hurd is not considered a
> priority by GNU, which shows in the lack of support for modern hardware.

Yes, this is unfortunate.

>> As a side note, if we don't have both together (libre hardware + ocap)
>> and we just have microkernel + ocap systems on top of proprietary
>> hardware, especially heavily "vendor controlled" systems, we could end
>> up much more screwed than we are even in our current systems, which is
>> why I think it's critical that we engage these things.
>
> I don’t understand this.  Why would the situation with microkernel +
> ocap on top of proprietary hardware be *worse* than the current
> situation of a monolithic ACL-based system on top of equally proprietary
> hardware?

The problem is that a much better implemented system will be harder to
break out of.  Right now many people "jailbreak" systems so they can
install free software on them.  We want to build watertight security
systems so that when users *control their hardware*, the programs on
their machines cannot do damage that they shouldn't be able to do.

But if the same watertight security system was applied but the lowest
capability layers were out of the user control, it might not be possible
to break free.

We can already see some of this today.  My understanding of why Intel
won't release a chip without ME, for instance, is that it's key to the
DRM systems that enforce playback of blue-ray players.  The enforcement
is checked on a hardware level.

>> In the book Rainbow's End (minor spoilers here) it's hinted that all
>> the users are running computers which have object capaiblity security
>> and are thus much more resilient to attacks, except that the bottom
>> most layer of the system is intentionally government compromised so
>> that all systems are effectively backdoored.  So, your sustem is
>> secure... except for the backdoor.
>
> … and *that* sounds like NSA’s SELinux again ;)

Heh :)

> Seriously, though, I’m not saying we should “simply” use SELinux to
> address this problem, but I think it can be one of the first stops on
> our road to better systems.
>
>> Anyway... the goal of this email was mostly just to try to get people
>> thinking about the direction we want to go long term.  Hope that's
>> useful/interesting even if it isn't an actual contribution of code
>> towards it ;)
>
> Code is often overrated.  I find it very important to discuss our
> visions of the future to know in what direction we have to move and how
> much effort we should make to get there in time.

Good point!  I feel better about my braindump then. ;)

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Ludovic Courtès]

Hi there!

Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:

>  - It's getting hard to trust our computers as in terms of our physical
>    hardware.  Companies like Purism are helping to build blobless
>    systems, but even then the hardware is built on un-auditable and
>    with growing apparent insecurity (Spectre, Meltdown) with little
>    chance of fixing things.  RISC-V has a libre instruction set, and in
>    the long term I think we want to support that.

Probably, though it’s hard to tell what RISC-V-based hardware will look
like—companies in a position to fabricate CPUs and to build computers
have goals not necessarily aligned with user freedom and autonomy.
RISC-V remains may be our best hope at this point, though.

>    In the long run, we'll want to support object capability based OS
>    designs which follow the principle of least authority, so a program's
>    vulnerabilities will be limited in scope.

Definitely!

>  - What paths do we have forward on that last one?
>
>    - Well, GNU Hurd is a microkernel + ocap system (while also trying
>      to be POSIX compatible).  Manolis has done much good work in
>      helping to make that a more feasible option for Guix users.
>
>    - There's also seL4 which has a verified security kernel, possibly
>      even seL4 with Genode.  I'm not sure how hard it will be to run
>      POSIX type things on Genode.
>
>    - There's also Google's recent work with Magenta/Fuschia.  From what
>      I've read, architecturally this looks right.  I think the reason
>      for worry here is the same difficulty the community has had to
>      build actual community and libre distributions on top of the
>      Android ecosystem could apply here.

Indeed.

We could also mention MINIX, which many of us are already using daily.
:-)

Putting aside Fuschia, I think the Hurd and MINIX are by far the
solutions that require the less work to be in a state where people with
“regular needs” like the rest of us to switch (MINIX is probably in that
state already.)

The Hurd already has a very advanced POSIX C library, which is not
negligible, especially compared to the other OSes.  Much progress has
been made in recent years wrt. drivers (using the Rump kernel in
particular.)  There are of course serious shortcomings, in particular
lack of 64-bit and SMP support.  But fixing these is relatively “little
work” in the grand scheme of things.

To put this in perspective, consider Linux namespaces: they have already
seen years of evolution, and the story of user namespaces shows that
it’s far from complete.

> As a side note, if we don't have both together (libre hardware + ocap)
> and we just have microkernel + ocap systems on top of proprietary
> hardware, especially heavily "vendor controlled" systems, we could end
> up much more screwed than we are even in our current systems, which is
> why I think it's critical that we engage these things.  In the book
> Rainbow's End (minor spoilers here) it's hinted that all the users are
> running computers which have object capaiblity security and are thus
> much more resilient to attacks, except that the bottom most layer of the
> system is intentionally government compromised so that all systems are
> effectively backdoored.  So, your sustem is secure... except for the
> backdoor.

Yeah.

> Anyway... the goal of this email was mostly just to try to get people
> thinking about the direction we want to go long term.  Hope that's
> useful/interesting even if it isn't an actual contribution of code
> towards it ;)

Another option that we can already start working on is to implement
least-authority in GNU/Linux through namespaces, as was discussed at:

  https://lists.gnu.org/archive/html/help-guix/2018-01/msg00056.html

Specifically there are two things we can implement:

  1. A ‘guix run’ command along the lines of
     <https://lists.gnu.org/archive/html/help-guix/2018-01/msg00108.html>.

  2. A mechanism that would allow, say, ‘guix package -i PKG --pola’ to
     automatically add “least-authority wrappers” around the binaries of
     PKG, pretty much like ‘guix pack --relocatable’ does (see
     ‘wrapped-package’ in (guix scripts pack)).

Not as bullet-proof as what an ocap OS or something like Qubes can
achieve, but already be an improvement.

For some packages (hi, ghostscript!), we might even want to add a
least-authority wrapper by default.

Thoughts?

Ludo’.

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> I’d love to get us closer to being able to run the GNU system with the
> Hurd and Guix underpinnings.  Unfortunately, Hurd is not considered a
> priority by GNU, which shows in the lack of support for modern hardware.

I know you know ;-) but there’s no such thing as GNU when it comes to
setting a direction and providing resources to pursue software
development goals.

So I think what’s important here is to change the Hurd’s image to
attract freedom-conscious and security-savvy people and organizations.
Like Guix, it needs a critical mass to take off.

Ludo’.

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Ludovic Courtès]

Hello Guix!

ludo@gnu.org (Ludovic Courtès) skribis:

> Specifically there are two things we can implement:
>
>   1. A ‘guix run’ command along the lines of
>      <https://lists.gnu.org/archive/html/help-guix/2018-01/msg00108.html>.
>
>   2. A mechanism that would allow, say, ‘guix package -i PKG --pola’ to
>      automatically add “least-authority wrappers” around the binaries of
>      PKG, pretty much like ‘guix pack --relocatable’ does (see
>      ‘wrapped-package’ in (guix scripts pack)).

Speaking of which, a colleague of mine told me about Whalebrew
<https://github.com/bfirsh/whalebrew>, which takes a somewhat similar
approach:

  Whalebrew creates aliases for Docker images so you can run them as if
  they were native commands. It's like Homebrew, but with Docker images.

  Docker works well for packaging up development environments, but there
  are lots of tools that aren't tied to a particular project: awscli for
  managing your AWS account, ffmpeg for converting video, wget for
  downloading files, and so on. Whalebrew makes those things work with
  Docker, too.

There’s this important difference:

  Packages are Docker images published on Docker Hub.

Ludo’.

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Ludovic Courtès]

Hi there!

Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:

>  - It's getting hard to trust our computers as in terms of our physical
>    hardware.  Companies like Purism are helping to build blobless
>    systems, but even then the hardware is built on un-auditable and
>    with growing apparent insecurity (Spectre, Meltdown) with little
>    chance of fixing things.  RISC-V has a libre instruction set, and in
>    the long term I think we want to support that.

Probably, though it’s hard to tell what RISC-V-based hardware will look
like—companies in a position to fabricate CPUs and to build computers
have goals not necessarily aligned with user freedom and autonomy.
RISC-V remains may be our best hope at this point, though.

>    In the long run, we'll want to support object capability based OS
>    designs which follow the principle of least authority, so a program's
>    vulnerabilities will be limited in scope.

Definitely!

>  - What paths do we have forward on that last one?
>
>    - Well, GNU Hurd is a microkernel + ocap system (while also trying
>      to be POSIX compatible).  Manolis has done much good work in
>      helping to make that a more feasible option for Guix users.
>
>    - There's also seL4 which has a verified security kernel, possibly
>      even seL4 with Genode.  I'm not sure how hard it will be to run
>      POSIX type things on Genode.
>
>    - There's also Google's recent work with Magenta/Fuschia.  From what
>      I've read, architecturally this looks right.  I think the reason
>      for worry here is the same difficulty the community has had to
>      build actual community and libre distributions on top of the
>      Android ecosystem could apply here.

Indeed.

We could also mention MINIX, which many of us are already using daily.
:-)

Putting aside Fuschia, I think the Hurd and MINIX are by far the
solutions that require the less work to be in a state where people with
“regular needs” like the rest of us to switch (MINIX is probably in that
state already.)

The Hurd already has a very advanced POSIX C library, which is not
negligible, especially compared to the other OSes.  Much progress has
been made in recent years wrt. drivers (using the Rump kernel in
particular.)  There are of course serious shortcomings, in particular
lack of 64-bit and SMP support.  But fixing these is relatively “little
work” in the grand scheme of things.

To put this in perspective, consider Linux namespaces: they have already
seen years of evolution, and the story of user namespaces shows that
it’s far from complete.

> As a side note, if we don't have both together (libre hardware + ocap)
> and we just have microkernel + ocap systems on top of proprietary
> hardware, especially heavily "vendor controlled" systems, we could end
> up much more screwed than we are even in our current systems, which is
> why I think it's critical that we engage these things.  In the book
> Rainbow's End (minor spoilers here) it's hinted that all the users are
> running computers which have object capaiblity security and are thus
> much more resilient to attacks, except that the bottom most layer of the
> system is intentionally government compromised so that all systems are
> effectively backdoored.  So, your sustem is secure... except for the
> backdoor.

Yeah.

> Anyway... the goal of this email was mostly just to try to get people
> thinking about the direction we want to go long term.  Hope that's
> useful/interesting even if it isn't an actual contribution of code
> towards it ;)

Another option that we can already start working on is to implement
least-authority in GNU/Linux through namespaces, as was discussed at:

  https://lists.gnu.org/archive/html/help-guix/2018-01/msg00056.html

Specifically there are two things we can implement:

  1. A ‘guix run’ command along the lines of
     <https://lists.gnu.org/archive/html/help-guix/2018-01/msg00108.html>.

  2. A mechanism that would allow, say, ‘guix package -i PKG --pola’ to
     automatically add “least-authority wrappers” around the binaries of
     PKG, pretty much like ‘guix pack --relocatable’ does (see
     ‘wrapped-package’ in (guix scripts pack)).

Not as bullet-proof as what an ocap OS or something like Qubes can
achieve, but already be an improvement.

For some packages (hi, ghostscript!), we might even want to add a
least-authority wrapper by default.

Thoughts?

Ludo’.

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Joshua Branson]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi there!
>
> Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:
>
>
> We could also mention MINIX, which many of us are already using daily.
> :-)

That's pretty awesome!  I didn't realize gnu developers were using
MINIX.

Also perhaps in a few years, x15 may turn into a workable hurd clone.

https://www.sceen.net/x15/

>
>
> Thoughts?
>
> Ludo’.

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Jonathan Brielmaier]

On 9/24/18 5:24 PM, Joshua Branson wrote:
> ludo@gnu.org (Ludovic Courtès) writes:
>> We could also mention MINIX, which many of us are already using daily.
>> :-)
> 
> That's pretty awesome!  I didn't realize gnu developers were using
> MINIX.

I guess it is a little different as you might think.

Regarding to
https://itsfoss.com/fact-intel-minix-case/
almost every modern (as in last 10 years) Intel CPU runs Minix as "base" system for the management engine (Intel ME).

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Adonay Felipe Nogueira]

[-- Attachment #1.1: Type: text/plain, Size: 2030 bytes --]

Em 24/09/2018 11:14, Ludovic Courtès escreveu:
> Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:
>>    - There's also Google's recent work with Magenta/Fuschia.  From what
>>      I've read, architecturally this looks right.  I think the reason
>>      for worry here is the same difficulty the community has had to
>>      build actual community and libre distributions on top of the
>>      Android ecosystem could apply here.
> 
> Indeed.
> 
> We could also mention MINIX, which many of us are already using daily.
> :-)
> 
> Putting aside Fuschia, I think the Hurd and MINIX are by far the
> solutions that require the less work to be in a state where people with
> “regular needs” like the rest of us to switch (MINIX is probably in that
> state already.)
> 
> The Hurd already has a very advanced POSIX C library, which is not
> negligible, especially compared to the other OSes.  Much progress has
> been made in recent years wrt. drivers (using the Rump kernel in
> particular.)  There are of course serious shortcomings, in particular
> lack of 64-bit and SMP support.  But fixing these is relatively “little
> work” in the grand scheme of things.
> 
> To put this in perspective, consider Linux namespaces: they have already
> seen years of evolution, and the story of user namespaces shows that
> it’s far from complete.

I don't know if what I'll say will be off-topic here given that this
list is about Guix development, not on general free/libre software
activism, but please forgive me anyways.

So, my worry is that if we somehow were to support Fuchsia and if it
were to be not strong auto-upgradable copyleft with community-oriented
enforcement, then we could actually loose the freedoms of the software
for the end user. This thought was initially presented by Eben Moglen
during one of his talks[1], but I just tried to bring the issue to Guix.

[1]
https://media.libreplanet.org/u/libreplanet/m/the-free-software-movement-in-the-age-of-trump/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

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

[Alex Vong]

[-- 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 --]

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

[Marius Bakke]

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

Hello!

Alex Vong <alexvong1995@gmail.com> writes:

> 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?

Thank you for taking the initiative!  This sounds great to me.  I
imagine the build systems could get an argument along the lines of
#:hardening-flags '(pie fortify stack-protector ...).

For gnu-build-system, I suppose we'd build up CFLAGS, LDFLAGS and
friends?  We'll also have to modify all packages that override those
variables.

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

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

[Joshua Branson]

Alex Vong <alexvong1995@gmail.com> writes:

> 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)...

I suppose it may be possible, but many of the original hurd developers
"concluded that microkernel design and system design are interconnected
in very intricate ways, and thus trying to use a third-party microkernel
will always result in trouble".  It is probably very non-trivial to port
to another microkernel.

https://www.gnu.org/software/hurd/history/port_to_another_microkernel.html

You might be interested in x15.  It's a hurd-like operating system, that
is probably a decade away from being useful to your average user.  But
it is developed by a long time Hurd developer:  Richard Braun.

https://www.sceen.net/x15/

>
> 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
>

--
Joshua Branson
Sent from Emacs and Gnus

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Christopher Lemmer Webber]

Adonay Felipe Nogueira writes:

> Em 24/09/2018 11:14, Ludovic Courtès escreveu:
>> Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:
>>>    - There's also Google's recent work with Magenta/Fuschia.  From what
>>>      I've read, architecturally this looks right.  I think the reason
>>>      for worry here is the same difficulty the community has had to
>>>      build actual community and libre distributions on top of the
>>>      Android ecosystem could apply here.
>> 
>> Indeed.
>> 
>> We could also mention MINIX, which many of us are already using daily.
>> :-)
>> 
>> Putting aside Fuschia, I think the Hurd and MINIX are by far the
>> solutions that require the less work to be in a state where people with
>> “regular needs” like the rest of us to switch (MINIX is probably in that
>> state already.)
>> 
>> The Hurd already has a very advanced POSIX C library, which is not
>> negligible, especially compared to the other OSes.  Much progress has
>> been made in recent years wrt. drivers (using the Rump kernel in
>> particular.)  There are of course serious shortcomings, in particular
>> lack of 64-bit and SMP support.  But fixing these is relatively “little
>> work” in the grand scheme of things.
>> 
>> To put this in perspective, consider Linux namespaces: they have already
>> seen years of evolution, and the story of user namespaces shows that
>> it’s far from complete.
>
> I don't know if what I'll say will be off-topic here given that this
> list is about Guix development, not on general free/libre software
> activism, but please forgive me anyways.
>
> So, my worry is that if we somehow were to support Fuchsia and if it
> were to be not strong auto-upgradable copyleft with community-oriented
> enforcement, then we could actually loose the freedoms of the software
> for the end user. This thought was initially presented by Eben Moglen
> during one of his talks[1], but I just tried to bring the issue to Guix.
>
> [1]
> https://media.libreplanet.org/u/libreplanet/m/the-free-software-movement-in-the-age-of-trump/

It's a valid concern, and one that applies to seL4 which I have
advocated on this thread as well.  However, I think we've seen a big
difference in "community-run" free software projects under a lax license
(which tend to stay free and good for the users) and "corporate-run"
throw-the-code-over-the-wall projects (which tend to be less so, and
Android is a great example).

However in a sense this is why we need to push, as a community, to get
our feet into the door of a secure, ocap-powered system for users.
Because users *need* and will want that security; systems are just so
dangerously insecure.  If we don't get the community in there, we'll
leave it up to and Android-like sorry state where you've just got some
large powers and users and communities desparately trying to figure out
how to stay free underneath them, and most users not even trying or know
how they could.

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

[Ludovic Courtès]

Hello,

Marius Bakke <mbakke@fastmail.com> skribis:

> Alex Vong <alexvong1995@gmail.com> writes:
>
>> 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?
>
> Thank you for taking the initiative!  This sounds great to me.  I
> imagine the build systems could get an argument along the lines of
> #:hardening-flags '(pie fortify stack-protector ...).
>
> For gnu-build-system, I suppose we'd build up CFLAGS, LDFLAGS and
> friends?  We'll also have to modify all packages that override those
> variables.

Sounds like a plan.  I think Alex proposed something along these lines
long ago.

The difficulty will lie in finding a way to pass those flags reliably
through the build system…

Ludo’.