grsecurity forums

Before it was wonderful and unsecure

After it it was secure bad Black *grmpf*
i love shell for real but sometimes i wanna see X ..
any suggestions ? *please* ?

May 12 12:13:49 router kdm[1728]: IO Error in XOpenDisplay
May 12 12:13:49 router kernel: PAX: terminating task: /usr/X11R6/bin/XFree86(X):1743, uid/euid: 0/0, EIP: 082083F8, ESP: 5ABCFE90
May 12 12:13:49 router kernel: PAX: bytes at EIP: 55 89 e5 83 ec 08 8b 45 08 a3 68 84 20 08 83 c4 f4 68 60 84
May 12 12:13:49 router kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (X:1743) UID(0) EUID(0), parent (kdm:1664) UID(0) EUID(0)
May 12 12:13:49 router kdm[1744]: IO Error in XOpenDisplay
May 12 12:13:49 router kernel: PAX: terminating task: /usr/X11R6/bin/XFree86(X):1764, uid/euid: 0/0, EIP: 082078B0, ESP: 5CC13540
May 12 12:13:49 router kernel: PAX: bytes at EIP: 55 89 e5 83 ec 08 8b 45 08 a3 20 79 20 08 83 c4 f4 68 18 79
May 12 12:13:49 router kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (X:1764) UID(0) EUID(0), parent (kdm:1664) UID(0) EUID(0)

Dorty wrote:8) Before it was wonderful and unsecure
After it it was secure bad Black *grmpf*
i love shell for real but sometimes i wanna see X ..
any suggestions ? *please* ?

chpax -pemrxs /usr/X11R6/bin/XFree86

ciao, Marc

Hello Guys, i have a XFree86 problem on a Gentoo box (2.4.20-gentoo-r5). So i know about chpax and used it. But my strange problem is: no user can run X only root. Any Suggestions?

Hi,

I just upgraded to grsec 1.9.10 and was wondering if XFree86 can be recompiled to make it run with the (new?) IO config option or if you just have to put up with not enabling it to run X?

Also you only need chpax -ps to make X work, not -pemrsx.

Cheers
Jon

Meths wrote:I just upgraded to grsec 1.9.10 and was wondering if XFree86 can be recompiled to make it run with the (new?) IO config option or if you just have to put up with not enabling it to run X?

it's not only a matter of modifying XFree86 but also the kernel as well. this is because the default fine-grained I/O port access control ends at port 1023 whereas PCI and similar cards require access to higher ports, so XFree86 uses iopl() instead which gives access to all I/O ports. i wrote a little patch back in January that would fix this (and that ioperm() bug as well, albeit inadvertantly), but i stopped once i realized how much more work it would be to make it SMP safe (needs the per CPU GDT patch) and give fine-grained control over PCI configuration accesses (which are multiplexed over a pair of I/O ports, so one would have to trap all such accesses, decode the arguments and emulate/deny access appropriately). if anyone's interested in developing it further, feel free to contact me.