Re: shm denials

[Ivan Gyurdiev <ivg2@xxxxxxxxxxx>]

>
>There are rules in the policy allowing read access for user domains and
>x client program domains to this type, to support shared memory
>communication with X as an optimization.  I would have expected the
>writes to occur to a shared memory object created by the user domain / x
>client domain (and thus labeled with user_tmpfs_t) that would then be
>read by X, but this seems to be a direct write to the shared memory
>object created by X.  I would expect the application to fall back to the
>slower IPC-based communication mechanism if this fails, so it shouldn't
>be fatal, but someone might want to assess the risk posed by allowing it
>(e.g. can a user domain / x client domain corrupt X by such direct
>writing to a shared memory object created by X).

True, this seems to cut OpenGL performance in half. 

Enforcing mode:

8071 frames in 5.0 seconds = 1614.200 FPS
9480 frames in 5.0 seconds = 1896.000 FPS
9480 frames in 5.0 seconds = 1896.000 FPS

Permissive mode / Enforcing mode with this allowed:

13682 frames in 5.0 seconds = 2736.400 FPS
14729 frames in 5.0 seconds = 2945.800 FPS
14694 frames in 5.0 seconds = 2938.800 FPS
14718 frames in 5.0 seconds = 2943.600 FPS
14640 frames in 5.0 seconds = 2928.000 FPS

audit(1108395306.088:0): avc:  denied  { write } for  pid=11720
comm=glxgears path=/SYSV00000000 (deleted) dev=tmpfs ino=38338560
scontext=user_u:user_r:user_t
tcontext=system_u:object_r:xdm_xserver_tmpfs_t tclass=file


-- 
Ivan Gyurdiev <ivg2@xxxxxxxxxxx>
Cornell University


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.