Bug 147335 - Various tmpfs denials
Summary: Various tmpfs denials
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-07 13:44 UTC by Ivan Gyurdiev
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-12 19:53:53 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ivan Gyurdiev 2005-02-07 13:44:56 UTC
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

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

audit(1107764104.478:0): avc:  denied  { write } for  pid=7292
comm=cage path=/SYSV00000000 (deleted) dev=tmpfs ino=10190848
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
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
tcontext=system_u:object_r:xdm_xserver_tmpfs_t tclass=file

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:

Additional info:

Comment 1 Ivan Gyurdiev 2005-02-07 13:53:39 UTC
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 

Now doesn't that make perfect sense - SElinux strict policy
and Unreal Tournament 2004 running on top of that :)

Comment 2 Daniel Walsh 2005-02-07 15:33:25 UTC
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?

Comment 3 Ivan Gyurdiev 2005-02-07 16:07:24 UTC
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. 

Comment 4 Daniel Walsh 2005-02-07 16:16:22 UTC
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.

Comment 5 Ivan Gyurdiev 2005-02-07 16:20:59 UTC
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...

Comment 6 Daniel Walsh 2005-02-07 16:31:02 UTC
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.


Comment 7 Ivan Gyurdiev 2005-02-07 17:47:22 UTC
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.

Comment 8 Daniel Walsh 2005-03-24 22:07:51 UTC
Are you still seeing this with the latest kernel?

Comment 9 Ivan Gyurdiev 2005-03-25 00:18:41 UTC
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%.


Comment 10 Daniel Walsh 2005-05-10 15:37:43 UTC
Mike do you have anything to add on this?  Should we just add a boolean to allow
X to execute the shared memory?

Comment 11 Ivan Gyurdiev 2005-05-10 15:48:34 UTC
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? 

Comment 12 Mike A. Harris 2005-05-13 16:34:44 UTC
Dan:  I've no opinion on the issue, but you might want to ask Kevin
too perhaps.

Note You need to log in before you can comment on or make changes to this bug.