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.