Mplayer: PT_GNU_STACK RWE
(re-sending to correct mplayer list..) Hi, I've subscribed to this list just to post this one question. The mplayer/mencoder executables are marked with PT_GNU_STACK RWE. This is true for the RPMS which I use from Livna.org (vs FC3), and also for mplayer CVS, compiled with gcc 3.4.3 (default FC rawhide compiler). This creates problems for the SELinux strict policy, and requires that special privileges be granted for mplayer as a "legacy domain". The question is, does mplayer really require an executable stack? I'm not a gcc expert of any kind, but from what I've read I understand that asm code causes gcc to mark the binary as requiring executable stack. I think it can be overriden with ld -z noexecstack. It would be a lot easier to write the mplayer security policy if it didn't require executable stack. -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University
On Tue, Feb 22, 2005 at 09:20:12PM -0500, Ivan Gyurdiev wrote:
(re-sending to correct mplayer list..)
Hi, I've subscribed to this list just to post this one question.
The mplayer/mencoder executables are marked with PT_GNU_STACK RWE. This is true for the RPMS which I use from Livna.org (vs FC3), and also for mplayer CVS, compiled with gcc 3.4.3 (default FC rawhide compiler).
This creates problems for the SELinux strict policy, and requires that special privileges be granted for mplayer as a "legacy domain".
The question is, does mplayer really require an executable stack?
I'm not a gcc expert of any kind, but from what I've read I understand that asm code causes gcc to mark the binary as requiring executable stack. I think it can be overriden with ld -z noexecstack.
It would be a lot easier to write the mplayer security policy if it didn't require executable stack.
-- I think it is required to use win32 dlls, but I may be wrong ;)
-- Gianluigi Tiesi <sherpya@netfarm.it> EDP Project Leader Netfarm S.r.l. - http://www.netfarm.it/ Free Software: http://oss.netfarm.it/
Hi, On Tue, Feb 22, 2005 at 09:20:12PM -0500, Ivan Gyurdiev wrote:
It would be a lot easier to write the mplayer security policy if it didn't require executable stack.
Just try what it break if it doesn't get it and tell us. Anyway one case where it was really needed (one of the software scalers) was recently fixed. Chances are that even if it needs it you wont notice it because you don't need that particular feature ;-). Greetings, Reimar Döffinger
On Wed, 2005-02-23 at 11:06 +0100, Reimar Döffinger wrote:
Hi, On Tue, Feb 22, 2005 at 09:20:12PM -0500, Ivan Gyurdiev wrote:
It would be a lot easier to write the mplayer security policy if it didn't require executable stack.
Just try what it break if it doesn't get it and tell us. Anyway one case where it was really needed (one of the software scalers) was recently fixed.
Well, the thing is, if it's marked RWE, and it isn't granted the appropriate privileges in SELinux, it doesn't work at all. The problem is, I think, that the kernel translates all PROT_READ requests in mmap and mprotect to PROT_READ | PROT_EXEC for things marked PT_GNU_STACK RWE, or for things missing PT_GNU_STACK. At that point anything without special permissions won't even link, so it doesn't work at all. mplayer could be granted those privileges, but that shouldn't be necessary if it doesn't need them.
Chances are that even if it needs it you wont notice it because you don't need that particular feature ;-).
Well, if that's the case then I don't know how me testing it will help. If you're saying this only occurs for some less frequently features, then you (the developers) are probably more qualified to find out what they are. I think linking with -z noexecstack should fix it - not sure. -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University
Hi, On Wed, Feb 23, 2005 at 06:41:26AM -0500, Ivan Gyurdiev wrote:
On Wed, 2005-02-23 at 11:06 +0100, Reimar Döffinger wrote:
On Tue, Feb 22, 2005 at 09:20:12PM -0500, Ivan Gyurdiev wrote:
It would be a lot easier to write the mplayer security policy if it didn't require executable stack.
Just try what it break if it doesn't get it and tell us. Anyway one case where it was really needed (one of the software scalers) was recently fixed.
Well, the thing is, if it's marked RWE, and it isn't granted the appropriate privileges in SELinux, it doesn't work at all. The problem is, I think, that the kernel translates all PROT_READ requests in mmap and mprotect to PROT_READ | PROT_EXEC for things marked PT_GNU_STACK RWE, or for things missing PT_GNU_STACK.
Well, and how are these settings changed?? Also, I know that the stack protection works correctly on AMD64 without any special measures (which is why one code part was changed), so I don't really understand what the problem with SELinux is...
Chances are that even if it needs it you wont notice it because you don't need that particular feature ;-).
Well, if that's the case then I don't know how me testing it will help. If you're saying this only occurs for some less frequently features, then you (the developers) are probably more qualified to find out what they are.
No, as at least I don't run SELinux I am not. Also I doubt I use MPlayer any more than you do.
I think linking with -z noexecstack should fix it - not sure.
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. 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... Greetings, Reimar Döffinger
Well, the thing is, if it's marked RWE, and it isn't granted the appropriate privileges in SELinux, it doesn't work at all. The problem is, I think, that the kernel translates all PROT_READ requests in mmap and mprotect to PROT_READ | PROT_EXEC for things marked PT_GNU_STACK RWE, or for things missing PT_GNU_STACK.
Well, and how are these settings changed??
These settings are changed by giving more permissions to mplayer in the SELinux security policy than it currently has. 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 b) Adding the LD flag -z noexecstack, which forces noexec
Also, I know that the stack protection works correctly on AMD64 without any special measures (which is why one code part was changed), so I don't really understand what the problem with SELinux is...
The problem is that mplayer has to be given broader permissions than it currently has in the SElinux policy. If it really needs those permissions, than that is fine. However, if mplayer doesn't actually need the stack to be executable, those permissions should not be granted, because they reduce the security of the system. The idea of SELinux is to not give applications more permissions than they need. That's why I asked if you really need the stack to be executable. It's not that mplayer doesn't work. It does work - if it is given the proper permissions. It's just that they seem too broad. Very few binaries on my system are actually marked RWE. Basically mplayer, lame, gpg, inkscape, and the Sun JRE. I've filed bugs with all of the above, so this list will hopefully go down. Executable stack = bad.
I think linking with -z noexecstack should fix it - not sure.
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. Most applications do not require exec. stack and are not marked by gcc as requiring that. Therefore they work on SElinux with no change. The applications that are marked as requiring executable stack need to have a special policy written for them, with broader permissions than the default generic domain. That's only on the Fedora strict policy, not on the targeted policy. If the app works without exec. stack, it would be better if it was marked PT_GNU_STACK RW, so it wouldn't need extra privileges and pose extra security risk when those are granted to it.
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. -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University
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? 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.
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.
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. Greetings, Reimar Döffinger
Hi, this was a quite informative read: http://lists.gnu.org/archive/html/gcl-devel/2004-06/msg00295.html Seems like the fact that we use asm code cause gcc to assume we need the stack executable :-(. They were going a lot too much for backwards-compatibility IMHO... Greetings, Reimar Döffinger
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@cornell.edu> Cornell University
On Wed, Feb 23, 2005 at 08:21:11AM -0500, Ivan Gyurdiev wrote:
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.
If the MPlayer binary is marked RWE... You still haven't told us if you tried compiling it without binary codec support. --Joey -- "Ours is not to question why, 'cause if we did, our heads would explode." --Megan
On Wed, 2005-02-23 at 10:57 -0600, Joey Parrish wrote:
On Wed, Feb 23, 2005 at 08:21:11AM -0500, Ivan Gyurdiev wrote:
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.
If the MPlayer binary is marked RWE... You still haven't told us if you tried compiling it without binary codec support.
The mplayer binary as currently found in livna.org, as well as the default CVS version with no special options are marked RWE. Tell me which options you'd like me to try to disable binary codec support... -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University
On Wed, Feb 23, 2005 at 12:19:17PM -0500, Ivan Gyurdiev wrote:
Tell me which options you'd like me to try to disable binary codec support...
./configure --disable-win32 --disable-dshow --disable-qtx --disable-xanim --disable-real Diego
On Wed, 2005-02-23 at 18:36 +0100, Diego Biurrun wrote:
On Wed, Feb 23, 2005 at 12:19:17PM -0500, Ivan Gyurdiev wrote:
Tell me which options you'd like me to try to disable binary codec support...
./configure --disable-win32 --disable-dshow --disable-qtx --disable-xanim --disable-real
Ok fair enough - no binary codecs, no RWE. So one possible solution is to compile mplayer without binary codec support. The problem is that Fedora users will download the one at Livna.org, which has binary codec support, and it won't work with strict policy. It won't even start, whether they have binary codecs, or not. So, seems like the solution is that legacy rules will stay, under a boolean, false by default for the "secure environment". Dwalsh, how about: allow_mplayer_legacy around the mplayer legacy rules? I mean all of them, not just legacy_domain(). -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University
On Wed, Feb 23, 2005 at 01:19:51PM -0500, Ivan Gyurdiev wrote:
On Wed, 2005-02-23 at 18:36 +0100, Diego Biurrun wrote:
On Wed, Feb 23, 2005 at 12:19:17PM -0500, Ivan Gyurdiev wrote:
Tell me which options you'd like me to try to disable binary codec support...
./configure --disable-win32 --disable-dshow --disable-qtx --disable-xanim --disable-real
Ok fair enough - no binary codecs, no RWE. So one possible solution is to compile mplayer without binary codec support. The problem is that Fedora users will download the one at Livna.org, which has binary codec support, and it won't work with strict policy. It won't even start, whether they have binary codecs, or not.
Then why not fix the one at livna.org? Or offer one "mplayer" package and one "mplayer-selinux" package? It shouldn't be difficult. --Joey -- "There are trivial truths and there are great truths. The opposite of a trivial truth is plainly false. The opposite of a great truth is also true." --Neils Bohr
Hi, On Wed, Feb 23, 2005 at 01:19:51PM -0500, Ivan Gyurdiev wrote:
On Wed, 2005-02-23 at 18:36 +0100, Diego Biurrun wrote:
On Wed, Feb 23, 2005 at 12:19:17PM -0500, Ivan Gyurdiev wrote:
Tell me which options you'd like me to try to disable binary codec support...
./configure --disable-win32 --disable-dshow --disable-qtx --disable-xanim --disable-real
Ok fair enough - no binary codecs, no RWE. So one possible solution is to compile mplayer without binary codec support. The problem is that Fedora users will download the one at Livna.org, which has binary codec support, and it won't work with strict policy. It won't even start, whether they have binary codecs, or not.
Better just apply the attached patch. Binary codecs that do not run with noexecstack also won't run on WinXPSP2 with "Data Execution Protection" activated, so if the codec is still maintained there should be a codec that works with it. But IMHO SELinux is for people that care about security and then binary codec support definitly should be disabled (not to say you better should use no media player at all *g* ) - so a separate package actually seems a much better idea to me. Greetings, Reimar Döffinger
Hi, On Wed, Feb 23, 2005 at 08:09:23PM +0100, Reimar Döffinger wrote:
Better just apply the attached patch. Binary codecs that do not run with
Applied to get it more testing. As far as I can tell it works and should work on other platforms as well (since unknown -z keywords are ignored)... Greetings, Reimar Döffinger
On Wednesday, 20 April 2005 at 14:08, Reimar Döffinger wrote:
Hi, On Wed, Feb 23, 2005 at 08:09:23PM +0100, Reimar Döffinger wrote:
Better just apply the attached patch. Binary codecs that do not run with
Applied to get it more testing. As far as I can tell it works and should work on other platforms as well (since unknown -z keywords are ignored)...
I'm fairly sure this won't work with Fedora Core 1's ld, as I remember the manpage not mentioning that keyword for -z. I'll test tonight. R. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"
Better just apply the attached patch. Binary codecs that do not run with noexecstack also won't run on WinXPSP2 with "Data Execution Protection" activated, so if the codec is still maintained there should be a codec that works with it.
Excellent. The patch results in binaries that are marked PT_GNU_STACK RW. Is this patch for me alone, or are you going to merge it in the mplayer source?
But IMHO SELinux is for people that care about security and then binary codec support definitly should be disabled (not to say you better should use no media player at all *g* ) - so a separate package actually seems a much better idea to me.
Well that's a separate issue that I don't want to go into right now - whether or not there should be a media player that works on strict policy, and does not allow binary codecs. -- However, I dislike how everyone always draws a line and colors everything on one side as "Secure" and everything on the other as "Non Secure". It's my opinion that inability to compromise security requirements to user requirements is bad for security. Thats why nobody runs SElinux in strict mode, and it doesn't get any testing. People figure out that what they want to do doesn't work, and turn the whole thing off. My personal computer is not a paranoid setup, and I won't trade functionality for security. At the same time I think that there's value in adding strict policy on my machine, even if some apps are considered "insecure". I don't care if mplayer can run binary codecs or not - I still appreciate it, when strict policy prevents, or makes more difficult other intrusions. Remember that SElinux is implemented by default in targeted mode on Fedora Core 3. That's a general purpose operating system. Someday it might even run in strict mode, at which point you have to deal with those issues. The security policy's need to keep things secure should not be incompatible with the user's requirements. I should be able to do what I want with my SElinux system, with minimal ease. That's why there's booleans, and you can change those to fit your requirements. The default setup is always the one that makes sense in a "secure environment". Anyway that's just my opinion. I'm not employed by RedHat, or the NSA, so it's not worth anything. -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University
Hi, On Wed, Feb 23, 2005 at 06:33:44PM -0500, Ivan Gyurdiev wrote:
Better just apply the attached patch. Binary codecs that do not run with noexecstack also won't run on WinXPSP2 with "Data Execution Protection" activated, so if the codec is still maintained there should be a codec that works with it.
Excellent. The patch results in binaries that are marked PT_GNU_STACK RW. Is this patch for me alone, or are you going to merge it in the mplayer source?
I'd like to get it into CVS but I don't know if it might cause some linkers to fail because of an unknown option. If so, a configure check would be necessary - but I hate to write configure checks. So I'd say it will be applied if somebody else takes care of it... Concerning security - well, non-executable stack might improve things a bit but not much IMHO - there a things that help a lot more. And I had the impression that SELinux is more effort than what makes sense to the "average" user, so I assumed you might have a specific reason to use it, thus the comments. Greetings, Reimar Döffinger
On Thu, 2005-02-24 at 01:52 +0100, Reimar Döffinger wrote:
Hi, On Wed, Feb 23, 2005 at 06:33:44PM -0500, Ivan Gyurdiev wrote:
Better just apply the attached patch. Binary codecs that do not run with noexecstack also won't run on WinXPSP2 with "Data Execution Protection" activated, so if the codec is still maintained there should be a codec that works with it.
Excellent. The patch results in binaries that are marked PT_GNU_STACK RW. Is this patch for me alone, or are you going to merge it in the mplayer source?
I'd like to get it into CVS but I don't know if it might cause some linkers to fail because of an unknown option. If so, a configure check would be necessary - but I hate to write configure checks. So I'd say it will be applied if somebody else takes care of it...
My version of ld has this, by the way: -z KEYWORD Ignored for Solaris compatibility It won't complain on nonsense -z values. Not sure if this is relevant.. -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University
On Thursday, 24 February 2005 at 12:46, Ivan Gyurdiev wrote:
On Thu, 2005-02-24 at 01:52 +0100, Reimar Döffinger wrote:
Hi, On Wed, Feb 23, 2005 at 06:33:44PM -0500, Ivan Gyurdiev wrote:
Better just apply the attached patch. Binary codecs that do not run with noexecstack also won't run on WinXPSP2 with "Data Execution Protection" activated, so if the codec is still maintained there should be a codec that works with it.
Excellent. The patch results in binaries that are marked PT_GNU_STACK RW. Is this patch for me alone, or are you going to merge it in the mplayer source?
I'd like to get it into CVS but I don't know if it might cause some linkers to fail because of an unknown option. If so, a configure check would be necessary - but I hate to write configure checks. So I'd say it will be applied if somebody else takes care of it...
My version of ld has this, by the way:
-z KEYWORD Ignored for Solaris compatibility
It won't complain on nonsense -z values. Not sure if this is relevant..
It is. What if we're compiling on Solaris with gcc built with native (not GNU) binutils? I can't test this case right now, so I'm putting this as food for thought. R. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"
Any progress on this issue - should I file a bugzilla to track it? On Fri, 2005-02-25 at 23:03 +0100, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 24 February 2005 at 12:46, Ivan Gyurdiev wrote:
On Thu, 2005-02-24 at 01:52 +0100, Reimar Döffinger wrote:
Hi, On Wed, Feb 23, 2005 at 06:33:44PM -0500, Ivan Gyurdiev wrote:
Better just apply the attached patch. Binary codecs that do not run with noexecstack also won't run on WinXPSP2 with "Data Execution Protection" activated, so if the codec is still maintained there should be a codec that works with it.
Excellent. The patch results in binaries that are marked PT_GNU_STACK RW. Is this patch for me alone, or are you going to merge it in the mplayer source?
I'd like to get it into CVS but I don't know if it might cause some linkers to fail because of an unknown option. If so, a configure check would be necessary - but I hate to write configure checks. So I'd say it will be applied if somebody else takes care of it...
My version of ld has this, by the way:
-z KEYWORD Ignored for Solaris compatibility
It won't complain on nonsense -z values. Not sure if this is relevant..
It is. What if we're compiling on Solaris with gcc built with native (not GNU) binutils? I can't test this case right now, so I'm putting this as food for thought.
R.
-- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University
On Tue, Mar 08, 2005 at 02:47:46PM -0500, Ivan Gyurdiev wrote:
Any progress on this issue - should I file a bugzilla to track it?
Sounds like a good idea. Diego
On Wed, Feb 23, 2005 at 01:19:51PM -0500, Ivan Gyurdiev wrote:
On Wed, 2005-02-23 at 18:36 +0100, Diego Biurrun wrote:
On Wed, Feb 23, 2005 at 12:19:17PM -0500, Ivan Gyurdiev wrote:
Tell me which options you'd like me to try to disable binary codec support...
./configure --disable-win32 --disable-dshow --disable-qtx --disable-xanim --disable-real
Ok fair enough - no binary codecs, no RWE.
Have you actually tested that? The main problem here is communication IMO. None of us has SELinux and you are asking us about SELinux support.. All we can do is give you educated guesses. YOU have to test it on a SELinux system. Diego
./configure --disable-win32 --disable-dshow --disable-qtx --disable-xanim --disable-real
Ok fair enough - no binary codecs, no RWE.
Have you actually tested that? The main problem here is communication IMO.
Yes of course I tested this - that's what I just did. This has nothing to do with SELinux, and anyone can check it. It's just a check whether or not the mplayer binary is marked RWE by the current gcc.
None of us has SELinux and you are asking us about SELinux support.. All we can do is give you educated guesses. YOU have to test it on a SELinux system.
Right... which is exactly what I am doing. SElinux is irrelevant for testing what you ask. -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University
On Wed, Feb 23, 2005 at 07:20:02AM -0500, Ivan Gyurdiev wrote:
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.
Or compile without binary codec support... ? I mean, if you need a secure environment, then loading executable code from a Windows DLL is not a good idea in the first place. Besides, I have never had a frequent need for binary codecs in practice. What environment requires all of SELinux, MPlayer, and binary codecs? --Joey -- "Are disorders necessarily bad?" --Ike
participants (6)
-
Diego Biurrun -
Dominik 'Rathann' Mierzejewski -
Gianluigi Tiesi -
Ivan Gyurdiev -
Joey Parrish -
Reimar Döffinger