SELinux and third party installers

[Daniel J Walsh]

Mike Hearn wrote:

>On Tue, 04 Jan 2005 13:01:01 -0500, Colin Walters wrote:
>  
>
>>Well, it's not beautiful.  But we need some solution.  Even if we got
>>changes into Mozilla, Helixplayer, etc. to use a restorecon equivalent
>>tomorrow, all of their existing tarballs would be broken, forever.  
>>
>>Actually I just saw in CVS that Dan added the following permission:
>>allow ldconfig_t lib_t:file r_file_perms;
>>    
>>
>
>Would that fix this?
>
>  
>
Yes

>Jan  4 19:07:22 littlegreen kernel: audit(1104865642.095:0): avc:  denied 
>{ read } for  pid=25822 exe=/sbin /ldconfig name=libiculx.so.26.2 dev=hdd2
>ino=2212143 scontext=root:system_r:ldconfig_t tcontext=root:object_
>r:lib_t tclass=file
>
>This is actually from doing an "apt-get install mono" on FC3 + apt +
>SELinux enabled so RPM was involved.
>
>The result is that running mono fails:
>
>[root at littlegreen tmp]# mono
>mono: error while loading shared libraries: libmono.so.0: cannot open
>shared object file: No such file or directory
>
>  
>
>>So essentially in the targeted policy only the targeted daemons will be
>>unable to read shared libraries not installed by RPM.  But for strict
>>policy the above permission doesn't help; we'd need to grant it to
>>everything which reads shlib_t.
>>    
>>
>
>That sounds a lot better :)
>
>  
>
That is what we have with this change.

>>One other option besides the daemon is to have ldconfig itself do an
>>automatic restorecon.  This is less efficient since it will do so for
>>every shared library, but given that ldconfig has always been the magic
>>command you run to make shared libraries work, it does seem somewhat of
>>a logical place to solve this particular problem.
>>    
>>
>
>  
>
An intersting idea...

>Yes that would help although unfortunately some (broken?) RPMs don't run
>ldconfig, on the grounds that /usr/lib is always scanned by the linker
>regardless of what the cache says.
> 
>  
>
>>Long term we can push 'install' at these ISVs, and maybe around FC5 or
>>FC6 if we have enough success, say that that's the only supported way to
>>install files to the system.
>>    
>>
>
>I'm not keen on this line of thinking: it's the type that means
>many of my Linux-native games and demos no longer run without lots of
>hacking about. Is the the benefit of restricting 3rd party binaries
>that don't opt-in worth the cost? 
>
>I tend to see SELinux as a tool to help enhance the security of programs
>that are explicitly interested in it, which goes hand in hand with
>a proper audit to flush out bad practice. Hopefully in future shipping
>policy with third party programs will become common. But I don't think
>it's wise to try and apply policy universally shot-gun style, especially
>not to legacy programs that don't expect it (which today, everything is).
>
>thanks -mike
>
>--
>fedora-selinux-list mailing list
>fedora-selinux-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  
>