Bug 147335 - Various tmpfs denials
Various tmpfs denials
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-07 08:44 EST by Ivan Gyurdiev
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Ivan Gyurdiev 2005-02-07 08:44:56 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:
Comment 1 Ivan Gyurdiev 2005-02-07 08:53:39 EST
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 :)
Comment 2 Daniel Walsh 2005-02-07 10:33:25 EST
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 11:07:24 EST
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 11:16:22 EST
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 11:20:59 EST
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 11:31:02 EST
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 
Comment 7 Ivan Gyurdiev 2005-02-07 12:47:22 EST
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 17:07:51 EST
Are you still seeing this with the latest kernel?
Comment 9 Ivan Gyurdiev 2005-03-24 19:18:41 EST
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 11:37:43 EDT
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 11:48:34 EDT
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 12:34:44 EDT
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.