[MPlayer-dev-eng] Mplayer: PT_GNU_STACK RWE

[Ivan Gyurdiev]

CC-ed to Ingo Molnar (There is a question about when 
gcc emits PT_GNU_STACK RWE). The discussion is about
how to remove the RWE marking from mplayer, so that
it no longer requires special SElinux permissions.
Those are required due to the READ implies EXECUTE logic 
in the kernel. 
==================================================================

On Wed, 2005-02-23 at 13:48 +0100, Reimar Döffinger wrote:
>Hi,
>I think there have been some misunderstandings, so let's start again *g*
>1) gcc is supposed to find out by itself if an application needs executable
>stack or not, right? Then how can I find out why it thinks MPlayer needs
>it?

I do not know. I'm a junior developer, and I'm not familiar with
gcc internals. I read online that it emits PT_GNU_STACK RWE 
when the code uses trampolines for nested functions, or when 
it sees asm blocks, because it doesn't know if the asm requires exec.
stack. Somebody on the inkscape list later claimed that it no longer
emits PT_GNU_STACK RWE for asm blocks, but I cannot confirm this.
The person to ask would be Ingo Molnar, I was told (cc-ed).

>2) MPlayer should not need an executable stack or heap (if necessary
>anonymous mmap should be used to fix that problem). If it does, it
>should be considered a bug and we will try to fix it.

Ok, good..
>
>> The PT_GNU_STACK marking is changed (as far as I understand it, though
>> I could be wrong), by:
>> 	a) Changing the code, so gcc does not emit the execute flag, or
>
>Unfortunately google is not very helpful to get more info on that...
>
>> 	b) Adding the LD flag -z noexecstack, which forces noexec

>I guess that would need at least another configure test, as there
>certainly are ld versions that do not support that :-(

...

>> >If applications don't work at all (without giving special permissions)
>> >on SELinux I'd consider it a bug that this flag is not default.
>> 
>> You're misunderstanding. The applications would work, but they would
>> require permissions we don't want to give them.
>
>I do understand that. Just that what you consider working (by giving
>special permissions) I consider not working.

Well, SELinux works by specifying a security policy for each program.
Special handling of each program is not a bug, it's a feature. The
security policy for mplayer restricts mplayer to the minimum privilege
possible. Of course, that can't be done for every program, because it is
overkill. Most programs run in a common domain called user_t, or
staff_t. Programs that need specialized permissions get their own
domain. I wrote the mplayer policy, originally to add the ability to
read the RTC clock, and some execmod permissions on /dev/zero. Later
it proved beneficial, because now we can transition mozilla into
this limited domain (when calling mplayer as a plugin), rather than
user_t where everything else runs. Now the question is, whether
additional privileges should go in there to allow:

# Legacy domain issues
legacy_domain($1_$2)
allow $1_$2_t lib_t:file execute;
allow $1_$2_t locale_t:file execute;
allow $1_$2_t sound_device_t:chr_file execute;

... where legacy_domain is:

# Define legacy_domain  for legacy binaries (java)
# "legacy" binary == lacks PT_GNU_STACK header, i.e. built with an old
# toolchain.  They cause the kernel to automatically start translating
all
# read protection requests to read|execute for backward compatibility on
# x86.  They will all need execmem and execmod, including execmod to
# shlib_t and ld_so_t unlike non-legacy binaries.

define(`legacy_domain', `
if (allow_execmem) {
allow $1_t self:process { execmem };
}
if (allow_execmod) {
#Required when starting with /lib/tls/libc-
allow $1_t { texrel_shlib_t shlib_t }:file execmod;
allow $1_t ld_so_t:file execmod;
}
allow $1_t ld_so_cache_t:file execute;
')

Those are currently in the Fedora policy. 
The idea is to get rid of them.
Do you really need to execute a locale file? Likely not.
Execute the ld cache file? ...etc

>> >At least 99% of all MPlayer code should run fine with a non-executable
>> >stack. The most critical parts are binary codec support, but IMHO you
>> >won't want that anyway in an environment that justifies using SELinux...
>> 
>> So, you're saying binary codec support requires the executable stack,
>> therefore you can't get rid of it? If that's the case, then maybe 
>> I should just give mplayer the appropriate permissions.
>
>First, binary codec support is needed for very few files. Second, the
>binary codec support does not need it in general afaik, but I do not
>know and I have no control over what those binary codecs do and need.

Right, but if the mplayer binary is marked RWE it causes denials no
matter of the binary support is used or not. 


Ivan Gyurdiev <ivg2 at cornell.edu>
Cornell University