Comments on: Lenny SE Linux on the Desktop http://etbe.coker.com.au/2008/08/04/lenny-se-linux-on-the-desktop/ Linux, politics, and other interesting things Thu, 09 Feb 2012 01:09:24 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Elmar Hoffmann http://etbe.coker.com.au/2008/08/04/lenny-se-linux-on-the-desktop/comment-page-1/#comment-15215 Elmar Hoffmann Tue, 05 Aug 2008 18:58:14 +0000 http://etbe.coker.com.au/?p=681#comment-15215 I'm only starting to look at SELinux, so I might have missed something there, but: Wouldn't a configuration where POP and IMAP daemons are allowed access to mail-specific subdirectories of user home directiories (such as ~/Maildir) be much better than both 1 or 2 in this case? Better than 1 from a principle of least privilege perspective (and also better than 2 if the restricted users have anything else than mail in their homedir), and better than 2 from a usability perspective not requiring an extra set of accounts. BTW, scanelf(1) from the pax-utils package can be used to easily find shared libs with text relocations on a system, e.g. like this: scanelf --quiet --textrel --recursive /lib /usr/lib I’m only starting to look at SELinux, so I might have missed something there, but:
Wouldn’t a configuration where POP and IMAP daemons are allowed access to mail-specific subdirectories of user home directiories (such as ~/Maildir) be much better than both 1 or 2 in this case?
Better than 1 from a principle of least privilege perspective (and also better than 2 if the restricted users have anything else than mail in their homedir), and better than 2 from a usability perspective not requiring an extra set of accounts.

BTW, scanelf(1) from the pax-utils package can be used to easily find shared libs with text relocations on a system, e.g. like this:
scanelf –quiet –textrel –recursive /lib /usr/lib

]]> By: uau http://etbe.coker.com.au/2008/08/04/lenny-se-linux-on-the-desktop/comment-page-1/#comment-15170 uau Mon, 04 Aug 2008 17:39:43 +0000 http://etbe.coker.com.au/?p=681#comment-15170 You seem to downplay the importance of performance in FFmpeg in the bugreport. Compiling with -fPIC and disabling the asm which is not compatible with that will drop H264 decoding performance over 15% on x86. And there is lots of content for which most systems are not "already fast enough". Only a minority of machines can play all high-definition H264 content without problems, and if a machine is running the x86 version instead of AMD64 then it most likely is not in that minority. Failing to play content in realtime usually makes it unwatchable in practice, so performance problems should not be considered less important than causing segfaults with the machine/video combinations in question. I consider it very unlikely that anyone would write PIC-compatible versions of all the FFmpeg asm before Lenny is released, at least not without unacceptably degrading performance. I'm not very familiar with SELinux, but if I understood correctly the problem with text relocations is you don't want the executable to have the permissions necessary for them because an attacker could write and then execute code with those permissions. Could that be avoided by making the executable drop such permissions after doing the text relocations during initial linking? If the text relocations are done and permissions dropped before any outside data is accessed then there should not be much risk of an attacker being able to exploit them. Unless there is some fundamental reason why such a system wouldn't work implementing it sounds more realistic than making all code on x86 work with a register less. You seem to downplay the importance of performance in FFmpeg in the bugreport. Compiling with -fPIC and disabling the asm which is not compatible with that will drop H264 decoding performance over 15% on x86. And there is lots of content for which most systems are not “already fast enough”. Only a minority of machines can play all high-definition H264 content without problems, and if a machine is running the x86 version instead of AMD64 then it most likely is not in that minority. Failing to play content in realtime usually makes it unwatchable in practice, so performance problems should not be considered less important than causing segfaults with the machine/video combinations in question.

I consider it very unlikely that anyone would write PIC-compatible versions of all the FFmpeg asm before Lenny is released, at least not without unacceptably degrading performance.

I’m not very familiar with SELinux, but if I understood correctly the problem with text relocations is you don’t want the executable to have the permissions necessary for them because an attacker could write and then execute code with those permissions. Could that be avoided by making the executable drop such permissions after doing the text relocations during initial linking? If the text relocations are done and permissions dropped before any outside data is accessed then there should not be much risk of an attacker being able to exploit them. Unless there is some fundamental reason why such a system wouldn’t work implementing it sounds more realistic than making all code on x86 work with a register less.

]]>