Qubes 4 with Grsec could make a big splash

313 views
Skip to first unread message

kev27

unread,
Nov 22, 2016, 1:57:56 PM11/22/16
to qubes-users
I saw this being retweeted by the Qubes account on Twitter. Can Grsec support still land in Qubes 4.0, or should we expect it for 4.1 or 4.2, etc?

I think if Grsec would be enabled by default in Qubes, it would be no question that Qubes is the most secure operating system out there.

kev27

unread,
Nov 22, 2016, 1:58:33 PM11/22/16
to qubes-users
On Tuesday, November 22, 2016 at 8:57:56 PM UTC+2, kev27 wrote:
> I saw this being retweeted by the Qubes account on Twitter. Can Grsec support still land in Qubes 4.0, or should we expect it for 4.1 or 4.2, etc?
>
> I think if Grsec would be enabled by default in Qubes, it would be no question that Qubes is the most secure operating system out there.

Forgot to add the link:

https://twitter.com/coldhakca/status/801107979126784000

Ronald Duncan

unread,
Nov 22, 2016, 2:49:07 PM11/22/16
to qubes-users
Will this be using the latest linux kernel since grsecurity only provide the latest version free.

jkitt

unread,
Nov 23, 2016, 6:29:13 PM11/23/16
to qubes-users

That's great news! Except PAX protections require more than just the kernel - they require PIE/PIC compiled binaries/SO's. There's also a number of security options that should be enabled in the GCC compiler (see the Gentoo hardened GCC profile). This means that the entire userspace would need to be recompiled and distributed as a hardened image - someone will need to do the legwork; and it will need to be signed by a trusted party.

jkitt

unread,
Nov 23, 2016, 6:34:08 PM11/23/16
to qubes-users
On Tuesday, 22 November 2016 19:49:07 UTC, Ronald Duncan wrote:
> Will this be using the latest linux kernel since grsecurity only provide the latest version free.

Yes, it will be an "unstable" kernel. A bare metal grsec kernel is actually available in Debian's testing repo. However, it is not compiled with optimal hypervisor guest options, and will be slow (if working at all) in a Xen guest environment. And because it's in the testing repo it probably doesn't receive as much attention to security as stable.

raah...@gmail.com

unread,
Nov 25, 2016, 6:38:21 AM11/25/16
to qubes-users

can you just tell us the options so we can compile it ourselves? paste the cfg or something.

raah...@gmail.com

unread,
Nov 25, 2016, 6:42:07 AM11/25/16
to qubes-users, raah...@gmail.com

does it need any other special patches? something like this to stay up to date you gonna need compile the multiple times a month.

Salmiakki

unread,
Nov 25, 2016, 7:14:10 AM11/25/16
to qubes-users
On Tuesday, November 22, 2016 at 7:57:56 PM UTC+1, kev27 wrote:
> I saw this being retweeted by the Qubes account on Twitter. Can Grsec support still land in Qubes 4.0, or should we expect it for 4.1 or 4.2, etc?
>
> I think if Grsec would be enabled by default in Qubes, it would be no question that Qubes is the most secure operating system out there.

Technically you could consider having grsec in dom0 or in AppVMs. It seems unklikely to me that it will appear as a default in either place.
In dom0 it isn't really necessary because it is extremely hardened and trustworthy already. In AppVMs it can be used already which is what this tweet is about but I doubt that the default Fedora template will change.

jkitt

unread,
Nov 25, 2016, 8:52:01 AM11/25/16
to qubes-users, raah...@gmail.com
On Friday, 25 November 2016 11:38:21 UTC, raah...@gmail.com wrote:
> can you just tell us the options so we can compile it ourselves? paste the cfg or something.

https://wiki.gentoo.org/wiki/Hardened/FAQ#Do_I_need_to_pass_any_flags_to_LDFLAGS.2FCFLAGS_in_order_to_turn_on_hardened_building.3F

Also:

> Can I add -fstack-protector-all or -fstack-protector in the make.conf CFLAGS?

> No, they will likely break the building of many packages, amongst others glibc.

in other words these options will break some packages - particularly glibc; ulibc is more flexible in that regards.

There's also: https://wiki.gentoo.org/wiki/Hardened/Toolchain

It's not as straightforward as you think. Perhaps you can build selected applications as statically linked with PIE, and place it in a grsec chroot instead - it would be a lot simpler.

I'd really like to see Gentoo (hardened) support, that and OpenBSD.

raah...@gmail.com

unread,
Nov 25, 2016, 4:41:32 PM11/25/16
to qubes-users, raah...@gmail.com

I meant if you were able to fpaste the .config file of your grsec kernel. I don't know anything about hardened building of the kernel. Is that nescessary? lol

raah...@gmail.com

unread,
Nov 25, 2016, 4:43:09 PM11/25/16
to qubes-users, raah...@gmail.com
On Friday, November 25, 2016 at 8:52:01 AM UTC-5, jkitt wrote:

I've always used a grsec kernel with baremetal debian. I just slete the default security over performance option. But I'm assuming some pax settings conflict with xen? So wanted to see your working .config file. Or maybe i'm wrong and should just try it myself...

I just kind of figure that since I'm using qubes whats the point is it really worth all the effort...

Patrick Schleizer

unread,
Nov 25, 2016, 6:16:09 PM11/25/16
to qubes...@googlegroups.com

jkitt

unread,
Nov 26, 2016, 12:08:03 AM11/26/16
to qubes-users
The point is that the security of a grsecurity protected system depends on the userspace being compiled in a special way. The binaries need to be compiled with pie, and shared objects need to be compiled with pic. There are also some other mitigations like SSP.

A grsecurity kernel on it's own is not adequate enough. Someone will need to distribute a hardened userspace.

The coldhaka kernel is in alpha. It's a start but not a solution.

raah...@gmail.com

unread,
Nov 26, 2016, 12:32:48 AM11/26/16
to qubes-users

its not nescessary to use grsec, but I guess makes it more secure.

The problem i'm having now trying not even a custom grsec kernel, but the debian 3.16 kernel from their repos. is that the vm I created when booting is asking me for a login? so if I type root it gives it to me. but it doesn't seem to be functioning right. The vm starts shows green light, then goes yellow light. And I can't load any programs from it like terminal.

I folloowed directions to install pvgrub2-xen in dom0.

Then in template vm installed qubes-kernel-vm-support grub2-common and installed kernel. then update-grub and shutdown. What did I do wrong?

raah...@gmail.com

unread,
Nov 26, 2016, 12:34:57 AM11/26/16
to qubes-users, raah...@gmail.com

forgot to add I get root with sudo xl console, and selected pvgrub2 in vm kernel settings.

Grzesiek Chodzicki

unread,
Nov 26, 2016, 3:30:39 AM11/26/16
to qubes-users
W dniu wtorek, 22 listopada 2016 19:57:56 UTC+1 użytkownik kev27 napisał:
> I saw this being retweeted by the Qubes account on Twitter. Can Grsec support still land in Qubes 4.0, or should we expect it for 4.1 or 4.2, etc?
>
> I think if Grsec would be enabled by default in Qubes, it would be no question that Qubes is the most secure operating system out there.

Or we could just wait for SubgraphOS guys to release a template of their system for Qubes.

Marek Marczykowski-Górecki

unread,
Nov 26, 2016, 5:59:11 AM11/26/16
to jkitt, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Nov 25, 2016 at 09:08:03PM -0800, jkitt wrote:
> The point is that the security of a grsecurity protected system depends on the userspace being compiled in a special way. The binaries need to be compiled with pie, and shared objects need to be compiled with pic. There are also some other mitigations like SSP.

Shared objects are always compiled as pic, these days. As for pie
executables - I think most distributions do this only for selected
binaries only.

> A grsecurity kernel on it's own is not adequate enough. Someone will need to distribute a hardened userspace.
>
> The coldhaka kernel is in alpha. It's a start but not a solution.
>


- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYOWr8AAoJENuP0xzK19csNYoH/iaSyiPdIK0quLx1nu3WaB1A
kgqEkY2W9/JIjprX7di8POL9xOSs6m0S7GAlefuhj4XOtY2vJSbfnaBt3AkKUK/9
G0x9o6UdmbjeiXPqGDEvHi0PfKdVer138IkdcgvFmBp9WAj0mgJdq1cKrZ9VfV8s
dBwX6R2uJkQ/F/EXaSuDNqy9xmI3x5Ea96pCQ8bcocj+7gSUzsVxl9F7Zkni3nUU
9ffnoxlzNMoxvqzi+liRCnwSYplNdcKkhIIJ/d/8Lz0ibyTjxkBPZFmUXYw6AKlr
+FK7wrD1ODYBeYEAcHEYpU3rmUkpmvErwR2PH5ZL9BpNZ8rp5z+NhJLSldQ72kM=
=lyTt
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages