grsecurity forums

I cannot run X.org.

Fatal server error:
xf86EnableIOPorts: Failed to set IOPL for I/O

Regardless if I use nvidia's drivers or the generic nv driver included with Xorg.

I enabled Sysctl support incase any of the options break the current setup.
I planned to enable all but those (if any) that would break it.

I should also point out that I didn't use the option of enabling options at startup.

Kernel: 2.6.11
GrSec Patch: 2.1.2
Xorg 6.8.2
Glibc 2.3.4
Dist: Slackware-current

I dont start grsec until after I start Xorg. But, I have the following problem:

Certain things are blocked with __*__...

Mar 6 02:55:26 __HOSTNAME__ grsec: (__USERNAME__:U:/usr/X11R6/bin/Xorg) denied executable mmap of /SYSV00000000 (deleted) by /usr/X11R6/bin/Xorg[X:__PID__] uid/euid:__NUM__/__NUM__ gid/egid:__NUM__/__NUM__, parent /usr/X11R6/bin/xinit[xinit:__PID__] uid/euid:__NUM__/__NUM__ gid/egid:__NUM/__NUM__


This happens when new programs are executed and try to open up a gui.. sometimes right after that in the logs, the program dies.. other times no.. what is this.. that file doesn't exist.. adding /SYSV00000000 rx doesn't help...

Firefox died like so, after the second one of those messages was logged:
The program 'Gecko' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
(Details: serial 83 error_code 10 request_code 148 minor_code 1)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

Ouch, looks like you're having about as much fun as me.

The same type of error is given by vmware-vmx.. a gradm -F -L when vmware-vmx was running made a acl with that file and with permission of x.. doing learning on Xorg results with that same acl entry.. however, the log still says that the process is unable to execute mmap that file... vmware does not seem phased by this.. it still works.. i think.. i put Xorg in learning mode so that I could use my system for now..

--hmhansolo

tuxq: did you enable the "disable raw i/o" feature by any chance?

-Brad

hmhansolo: I've posted a new patch to the server that should fix your problem. Let me know if it does.

-Brad

If that doesn't fix the problem, a workaround would be adding the rule:

/SYSV* x

to your policy.

-Brad

spender wrote:tuxq: did you enable the "disable raw i/o" feature by any chance?

I was under the impression that nothing was enabled on startup until the option was enabled in /proc/sys/kernel/grsecurity/.
I guess it's just some of the options that can do so.

"Disable privileged I/O" is the culprit.

That's true if the "enable sysctl features by default" feature isn't enabled, and only for features which support sysctl tuning (the help for each feature will tell you if it supports sysctl or not).

-Brad

spender wrote:That's true if the "enable sysctl features by default" feature isn't enabled, and only for features which support sysctl tuning (the help for each feature will tell you if it supports sysctl or not).

-Brad

That's what I get for doing that at 5 in the morning with 3 hours of sleep

Doing `/SYSV* x` fixed the problem. I have a couple questions. What does the /SYSV* mean.. and why does /SYSV* work while /SYSV00000 doesnt?

--hmhansolo

/SYSV* uses the filename-based regex matching, while /SYSV000000 gets entered into the system as a file that doesn't exist yet and thus is marked as "deleted" until it gets created. The problem is that the /SYSV000000 file doesn't get created like a normal file is created by the user, so the RBAC system doesn't know it was created, and thus does not know what inode/device number it has. So when the mmap of the file is done, we can't find the inode/device corresponding to that file, so the lookup fails. I should have a fix for the problem soon.

-Brad

Thanks man... one other question.. what is this "/SYSV000000" file.. why is Xorg and vmware even trying to use these files??

--hmhansolo

It's a fake file essentially (it doesn't actually persist on the filesystem: when it's created it's already marked as unlinked) that is created by the use of shared memory.

-Brad

The problem is fixed in 2.1.3. The /SYSV0000000 entry will be treated as a globbed object instead of a real file.

-Brad