Bug 81582 - Colord fails to start on hardened kernel
Summary: Colord fails to start on hardened kernel
Status: NEEDINFO
Alias: None
Product: colord
Classification: Unclassified
Component: daemon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Richard Hughes
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-21 02:46 UTC by Luke
Modified: 2014-08-02 03:21 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg log (1.14 KB, text/plain)
2014-07-21 02:46 UTC, Luke
Details

Description Luke 2014-07-21 02:46:25 UTC
Created attachment 103164 [details]
dmesg log

Running Arch Linux with Hardened Kernel it is not possible to use colord. Even after setting all protection off the binary (- PaX flags: -p-s-m-xE--r [/usr/lib/colord/colord]).

This is a possible security risk and should be investigated.

Thanks.
Comment 1 Richard Hughes 2014-07-28 12:41:39 UTC
(In reply to comment #0)
> Running Arch Linux with Hardened Kernel it is not possible to use colord.
> Even after setting all protection off the binary (- PaX flags: -p-s-m-xE--r
> [/usr/lib/colord/colord]).

Define "use" -- does the binary run? If so, does the binary get any log output when run with --verbose as root?

> This is a possible security risk and should be investigated.

Sure, I'd love to if grsec and PaX was available upstream or in Fedora...
Comment 2 Daniel Micay 2014-08-02 03:21:22 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > Running Arch Linux with Hardened Kernel it is not possible to use colord.
> > Even after setting all protection off the binary (- PaX flags: -p-s-m-xE--r
> > [/usr/lib/colord/colord]).
> 
> Define "use" -- does the binary run? If so, does the binary get any log
> output when run with --verbose as root?
> 
> > This is a possible security risk and should be investigated.
> 
> Sure, I'd love to if grsec and PaX was available upstream or in Fedora...

See https://github.com/thestinger/paxd/issues/11 for a more detailed report by the same person. An MPROTECT exception would have worked, but it wasn't being set correctly. Ideally an MPROTECT exception wouldn't be required (prevents injecting at code at runtime, so you can't go from ROP -> shellcode) but I don't actually run into this issue when I start colord with the grsecurity kernel.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.