On Monday 04 August 2008 20:59, Loïc Minier <[EMAIL PROTECTED]> wrote: > On Mon, Aug 04, 2008, Russell Coker wrote: > > http://etbe.coker.com.au/2007/02/10/execmod/ > > > > The above URL has background information on the execmod denial from SE > > Linux. > > If you want to file bugs about binaries not using -fpic / -fPIC on > i386, then I think you need to start a wider discussion on > debian-devel@: this was debated and I understand there's now an > exception for performance critical code (such as libswscale's case): > <http://www.debian.org/doc/debian-policy/footnotes.html#f61>
The references you provide seem to indicate that the exception is for the case where faster assembly is not available. IE you have a choice between fast assembly and a slower compiled language. While if the difference is only 10% (between two different versions of assembly code) then PIC is the way to go. I expected that the probability of you including my patch to disable the assembler was low (although a similar patch is in the Fedora tree for libtheora), but if nothing else it clearly illustrates where the problem is for anyone who wants to have a go at writing some assembler. > I see two ways to go forward: implement a way to disable execution of > such binaries when under SELINUX, or force usage of -fPIC, even in > performance critical code. If the performance critical code is going to be handling data from sources of low integrity (EG playing video downloaded from youtube etc) then I think that we want all the available security features enabled! But having library A try and load library B at runtime and then load library C if B fails (where B is the non-PIC version and C is the PIC version) would be a viable option. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]