Set user xattrs and patch cffi for PaX

[phabricator-migrator]

Information

ID: 210
PHID: PHID-TASK-xuufugvactrf5zh2fvu5
Author: John
Status at Migration Time: invalid
Priority at Migration Time: Wishlist

Description

Currently, whonixcheck and sdwdate don’t work with a kernel patched with grsecurity. This is because of two problems:

• /usr/bin/python2.7 is not labelled with user.pax.flags=‘E’
• cffi tries to create rwx pages

The first is easy to fix, just setfattr -n user.pax.flags -v E /usr/bin/python2.7

The second requires a patch¹. Given that Whonix uses Debian stable, I’m guessing that it will take a Very Long Time Indeed until a working release ends up in Whonix without preemptive action.

¹ https://bitbucket.org/cffi/cffi/issue/177/foo-segfaults-with-grsec-denied-rwx-mmap

Comments

---

Patrick

2015-03-03 15:20:09 UTC

We don’t have the manpower to ship a custom patched kernel at this time.

Isn’t this a patch that should be suggested to the grsecurity developers?

Please share how you got grsecurity working in Whonix in a separate ticket or T203.

---

John

2015-03-04 08:32:18 UTC

! In T210#2722, @Patrick wrote:
We don’t have the manpower to ship a custom patched kernel at this time.

Isn’t this a patch that should be suggested to the grsecurity developers?

Please share how you got grsecurity working in Whonix in a separate ticket or T203.

I didn’t mean to imply that you should ship a custom kernel, only that it would be nice if you set the appropriate xattrs and ideally patched your copy of cffi.

The patch shouldn’t be suggested to grsecurity developers, since it’s a patch to cffi. The penultimate comment in the linked thread explains what it does.

As for how I got grsecurity working in Whonix, I simply copied over a kernel (hardened-sources) from a Gentoo install.

---

Patrick

2015-03-04 16:22:40 UTC

! In T210#2748, @John wrote:
I didn’t mean to imply that you should ship a custom kernel, only that it would be nice if you set the appropriate xattrs

Isn’t this something that should be rather suggested and implemented to Debian’s python package or python upstream?

and ideally patched your copy of cffi.
The patch shouldn’t be suggested to grsecurity developers, since it’s a patch to cffi. The penultimate comment in the linked thread explains what it does.

I see. cffi merged the patch. I don’t think we have the manpower to maintain patched versions of packages in Whonix’s repository. So it will likely indeed take a long time until Debian stretch.

---

John

2015-03-23 02:21:10 UTC

I see. cffi merged the patch. I don’t think we have the manpower to maintain patched versions of packages in Whonix’s repository. So it will likely indeed take a long time until Debian stretch.

Just fyi, the problem isn’t cffi, but a much earlier change in libffi (included in 3.1).

I hadn’t quite realized just how antiquated debian stable was, and so had assumed it must be the later cffi problem. I tried installing libffi from debian testing, but that pulled in glibc from testing, which triggered what seemed like a complete removal of whonix packages. I had no idea how to specify dependency preferences in apt as would be specified by USE flags in portage, so I gave up.

wrt taking this issue to debian, considering the manpower of debian and its nonchalance toward rwx pages thus far, I think that doing so would be painful to say the least.

It’s probably easier to just inspect and copy whonix config over to Gentoo and use that until libffi 3.1 reaches debian stable.

---

HulaHoop

2015-05-20 13:16:36 UTC

Why not set PaX exceptions for cffi with paxctl? Exceptions for any flags can be done per binary. It should work but it won’t fully benefit from PaX until upstream cffi supports mprotect.

---

John

2015-05-21 21:24:35 UTC

! In T210#4702, @HulaHoop wrote:
Why not set PaX exceptions for cffi with paxctl? Exceptions for any flags can be done per binary. It should work but it won’t fully benefit from PaX until upstream cffi supports mprotect.

Primarily because granting rwx pages isn’t the only problem. Without patching ffi tries to create and then execute writable files(!). The patch makes ffi see that it’s on a kernel that enforces basic security/sanity, and if it is, elect not to do so.

Also, ELF header marking has been deprecated for over a year, so I don’t build my kernels with support for it.* This is a good thing, because altering the hash of installed files removes any “outsourced” trust afforded by using upstream binaries.

* Running a secure system on hardened Gentoo profiles is piss easy. I hadn’t quite (read: at all) appreciated that fact until I tried to use Whonix/debian.

---

HulaHoop

2015-05-22 02:15:49 UTC

Primarily because granting rwx pages isn’t the only problem. Without patching ffi tries to create and then execute writable files(!)

Yes I implied there is a temporary security tradeoff because python won’t be fully protected but I still think the problem is not a blocker for grsecurity support because exceptions can still make cffi work. Interpreters like python and java need PaX exceptions to work.

---

John

2015-05-22 02:52:38 UTC

! In T210#4790, @HulaHoop wrote:
Primarily because granting rwx pages isn’t the only problem. Without patching ffi tries to create and then execute writable files(!)

Yes I implied there is a temporary security tradeoff because python won’t be fully protected but I still think the problem is not a blocker for grsecurity support because exceptions can still make cffi work. Interpreters like python and java need PaX exceptions to work.
I don’t understand what part of that quote you’re addressing. Writable files are outside of PaX’s scope. TPE is what protects against writable executables, and TPE isn’t part of PaX. Sure, you could disable it, if you like living dangerously. I sure as hell wouldn’t.

---

HulaHoop

2015-05-22 05:28:02 UTC

There are ways to make TPE exemptions more fine grained than shutting it off completely. Add the python scripts under a separate group then use tpe_invert. Its not ideal but definitely better than nothing and better than not having grsecurity at all until the next Debian stable.

grsec manual:

kernel.grsecurity.tpe_invert
If you say Y here, the group you specify in the TPE configuration will
decide what group TPE restrictions will be disabled for. This
option is useful if you want TPE restrictions to be applied to most
users on the system. If the sysctl option is enabled, a sysctl option
with name “tpe_invert” is created. Unlike other sysctl options, this
entry will default to on for backward-compatibility.

---

John

2015-05-22 05:56:30 UTC

! In T210#4792, @HulaHoop wrote:
There are ways to make TPE exemptions more fine grained than shutting it off completely. Add the python scripts under a separate group then use tpe_invert. Its not ideal but definitely better than nothing and better than not having grsecurity at all until the next Debian stable.

grsec manual:

kernel.grsecurity.tpe_invert
If you say Y here, the group you specify in the TPE configuration will
decide what group TPE restrictions will be disabled for. This
option is useful if you want TPE restrictions to be applied to most
users on the system. If the sysctl option is enabled, a sysctl option
with name “tpe_invert” is created. Unlike other sysctl options, this
entry will default to on for backward-compatibility.

You’ll also have to disable GRKERNSEC_TPE_ALL, since TPE then blocks any executable file that’s world-writable regardless of tpe_gid’s value (which /tmp usually is). I suggest having a seriously strict MAC/RBAC policy before considering turning it off though (on your own machines: I agree with your implication that debian users are fscked already ;))

---

HulaHoop

2017-04-29 16:20:49 UTC

upstream ceased open development: grsecurity