Red Hat Bugzilla – Bug 147335
Various tmpfs denials
Last modified: 2007-11-30 17:10:59 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041228 Firefox/1.0 Fedora/1.0-8 Description of problem: Look, various apps not shipped by Fedora require write and execute to shm files. Should user_t have any of those permissions? Note that at least one of those applications is shipped by Fedora: Cage is a screensaver part of xscreensaver, I believe. audit(1107731077.488:0): avc: denied { execute } for pid=5150 comm=setiathome path=/SYSV73657469 (deleted) dev=tmpfs ino=4259854 scontext=user_u:user_r:user_t tcontext=user_u:object_r:user_tmpfs_t tclass=file audit(1107762308.379:0): avc: denied { execute } for pid=6767 comm=ut2004-bin path=/SYSV00000000 (deleted) dev=tmpfs ino=9961489 scontext=user_u:user_r:user_t tcontext=user_u:object_r:user_tmpfs_t tclass=file audit(1107764104.478:0): avc: denied { write } for pid=7292 comm=cage path=/SYSV00000000 (deleted) dev=tmpfs ino=10190848 scontext=user_u:user_r:user_t tcontext=system_u:object_r:xdm_xserver_tmpfs_t tclass=file audit(1107766060.080:0): avc: denied { execute } for pid=7453 comm=ut2004-bin path=/SYSV00000000 (deleted) dev=tmpfs ino=10190848 scontext=user_u:user_r:user_t tcontext=system_u:object_r:xdm_xserver_tmpfs_t tclass=file audit(1107767207.530:0): avc: denied { write execute } for pid=9006 comm=ut2004-bin path=/SYSV00000000 (deleted) dev=tmpfs ino=10190848 scontext=user_u:user_r:user_t tcontext=system_u:object_r:xdm_xserver_tmpfs_t tclass=file Version-Release number of selected component (if applicable): selinux-policy-strict-1.21.8-4 How reproducible: Didn't try Steps to Reproduce: Additional info:
This is more of a question than a request for change of any kind. If you think it would be more appropriate to have those apps in their own domain then so be it - they're legacy anyway and need legacy_domain(). I'm just trying to establish the easiest way to get this stuff to work on a fedora strict system. Something should be done about the screensaver though. Now doesn't that make perfect sense - SElinux strict policy and Unreal Tournament 2004 running on top of that :)
No I don't think allowing these privs is a good idea. We could don't audit them. What happens to cage when it hits this error?
Perhaps put those programs in their own domain, with their own private tmpfs context and give write/execute to that? Is that comparable to the execmem permission? For screensavers, nothing bad *seems* to happen, but when testing I notice that I get this denial for every screensaver, and not just cage.
We could add something like dontaudit $1_t $1_tmpfs_t:file execute; dontaudit $1_t xdm_xserver_tmpfs_t:file { execute write }; To base_user_macros.
Well why do those denials occur? If the application(s) need this capability then it seems to me that it should be allowed instead of dontaudit. I should learn how /dev/shm is used...
No, Just because an application wants privs does not necessarily mean we should allow it. There is/could be security ramifications. Screensavers have been built with lots of extra privs that they do not need in a locked down system. Radar for instance wants to ping in order to get the radar screen to be random. Not exactly a valid reason to allow an application to have access to raw sockets. Dan
Actually it looks like only the GL screensavers are doing something with shm. They use shmat() and shmdt(). I suspect the nvidia GL library is at fault here, and it causes denials for both UT and the X screensavers.
Are you still seeing this with the latest kernel?
There's two separate problems here. One is the execute problem, which I think should not occur with checkprotreq enabled. The other is the inability to write to xdm shm, which should still occurs. I'll test again when I get back from Spring break, but I think I still get the write denials. Stephen Smalley said someone should audit X for whether this permission should be allowed or not, or a boolean should be added for it. I wanted to add a boolean, but I figured x_client_macros should become the central point for X-related permissions first (so boolean can be added there). It's important that this is fixed somehow, because otherwise OpenGL performance is reduced by 50%.
Mike do you have anything to add on this? Should we just add a boolean to allow X to execute the shared memory?
I didn't realize this bug was still open: So, to review: - execute denial: currently no boolean, goes away with checkprotreq=1 Caused by lack of PT_GNU_STACK, or PT_GNU_STACK RWE (??) - write denial: handled by the patches I sent for x_client, which were merged - they add a new boolean called allow_write_xhm. Perhaps those should be enabled by default, without a boolean?
Dan: I've no opinion on the issue, but you might want to ask Kevin too perhaps.