FS#40685 - [paxd] Latest tor no longer works with linux-grsec + paxd

Attached to Project: Community Packages
Opened by Anonymous (reallybmn) - Wednesday, 04 June 2014, 15:27 GMT
Last edited by Daniel Micay (thestinger) - Wednesday, 11 June 2014, 18:29 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Daniel Micay (thestinger)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
As of the latest tor-0.2.4.22-1-x86_64.pkg.tar.xz which was released May 27th, tor no longer functions on linux-grsec kernel. The previous version tor-0.2.4.21-3-x86_64.pkg.tar.xz works without any errors. This is of concern as Grsec is properly blocking a strange function in the package.

This bug is also filed upstream and they would like to know if any changes were made in the compilation of this package.
https://trac.torproject.org/projects/tor/ticket/12192

Additional info:
* package version(s): 0.2.4.22-1
* config and/or log files etc.
[ 1392.928420] grsec: denied RWX mprotect of /usr/bin/tor by /usr/bin/tor[tor:1003] uid/euid:1000/1000 gid/egid:100/100, parent /usr/bin/bash[bash:1001] uid/euid:1000/1000 gid/egid:100/100

scanelf -qtmyR /usr/bin/
TEXTREL /usr/bin/tor
TEXTREL /usr/bin/tor-gencert
TEXTREL /usr/bin/tor-resolve


Steps to reproduce:
Use linux-grsec with paxd, you will notice immediately that the latest version of tor will not execute.
Previous version works fine and can be tested using Arch Rollback Machine mirror:
http://seblu.net/a/arm/packages/t/tor/
This task depends upon

Closed by  Daniel Micay (thestinger)
Wednesday, 11 June 2014, 18:29 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Closing in favour of https://bugs.archlinux.org/40802 as this is really a binutils issue.
Comment by Johannes Löthberg (demize) - Wednesday, 04 June 2014, 15:38 GMT
Why didn't you just check the diff instead of asking if anything was changed?

https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/tor
Comment by Gaetan Bisson (vesath) - Wednesday, 04 June 2014, 15:45 GMT
Tor works fine with linux. This is a bug for linux-grsec.
Comment by Daniel Micay (thestinger) - Wednesday, 04 June 2014, 15:46 GMT
This is not really an issue in tor, linux-grsec or a missing exception in paxd. It occurs because tor is built as a position independent executable. The current binutils package has a backported PIE-related patch causing the linker to perform a relocation violating the PaX mprotect rules. It is unfortunate, but I don't know enough about relocations to be sure if this is a bug. Building with ld.gold instead of ld.bfd is a workaround, but it would be best to tackle this upstream in binutils.
Comment by Daniel Micay (thestinger) - Wednesday, 04 June 2014, 15:56 GMT
By the way, in the future, please report missing exceptions to https://github.com/thestinger/paxd since it's an upstream (sort of) bug in my exception list. This one is a special case though, since the correct solution won't be adding another exception to the list, but rather figuring out what is going wrong in ld.bfd.
Comment by Anonymous (reallybmn) - Wednesday, 04 June 2014, 16:49 GMT
@thestinger: I was unaware that this was a paxd specific issue, also adding doing paxctl -psmxer [all off] doesn't solve the problem.

Could someone please post a link or attach the build configuration for this package? I was unable to locate it. Downloading from the official tor website and compiling from source with the current binutils from main repos works fine and does not suffer the TEXTREL issue. So it is definitely something to do with the build process, I am unsure why we would need this package to be position-independent if that is a special setting?

Thanks.


Comment by Daniel Micay (thestinger) - Wednesday, 04 June 2014, 17:02 GMT
The linux-grsec package doesn't enable PaX by default so this isn't a linux-grsec issue, because PaX is working as intended. It's also only built with support for the modern exception system based on extended attributes so paxctl will not do anything beyond mangling the binaries. If an exception is missing, then it's a missing feature in the paxd project's exception list to be reported there.

Anything built as a position independent executable (PIE) with the ld.bfd in Arch's binutils package will require a PaX MPROTECT exception at the moment due to what appears to be a bug in one of the backported commits. Tor is built as PIE because they care about security and it's an important security feature, as otherwise there is only ASLR for libraries and not the executable. Since this is a binutils issue, I would rather work towards fixing it upstream than adding an exception.

As I said, it's possible to work around this issue by building with ld.gold instead of ld.bfd. That's likely as simple as passing `-fuse-ld=gold` in LDFLAGS while building tor. Building with clang as CC would also work, since clang defaults to using ld.gold instead of ld.bfd (it's faster).

Loading...