postfix, procmail and SELinux - No Go

[Paul Howarth]

Marc Schwartz wrote:
> On Tue, 2006-07-18 at 16:15 +0100, Paul Howarth wrote:
>>>>> type=AVC msg=audit(1153053408.030:4599): avc:  denied  { execmod } for  pid=6019 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" d ev=hdc7 ino=3116816 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file
>>>>> type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125 success=no exit=-13 a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" sub j=user_u:system_r:prelink_t:s0
>>>>> type=AVC_PATH msg=audit(1153053408.030:4599):  path="/usr/lib/libGLcore.so.1.0.8762"
>>>>> type=AVC msg=audit(1153053408.034:4600): avc:  denied  { execmod } for  pid=6022 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2" dev=hdc7 ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file
>>>>> type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125 success=no exit=-13 a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2" exe="/lib/ld-2.4.so" subj= user_u:system_r:prelink_t:s0
>>>>> type=AVC_PATH msg=audit(1153053408.034:4600):  path="/usr/lib/tls/libnvidia-tls.so.1.0.8762"
>>>> Do you have nvidia video drivers installed using the nvidia installer 
>>>> rather than an RPM package? If so, you should probably see:
>>>> http://www.city-fan.org/tips/ProprietaryVideoDriverWarning
>>> Yep.  I have never had a problem with them (dating back to RH 8.0, all
>>> on Dell laptops) and this is the first time that I had noted any avc's
>>> related to them.
>>>
>>> I have a script that I ran when I first moved to FC5 to set the
>>> following:
>>>
>>> /usr/sbin/setsebool -P allow_execstack=1
>>> /usr/sbin/setsebool -P allow_execmod=1
>>>
>>> based upon documents that I had found elsewhere.
>> That's somewhat overkill and I wouldn't want to do that.
> 
> Curiously, that approach is still noted in a variety of places,
> including FedoraFaq.org:
> 
> http://www.fedorafaq.org/#nvidia
> 
> and others:
> 
> http://www.mjmwired.net/resources/mjm-fedora-fc5.html#nvidia
> http://stanton-finley.net/fedora_core_5_installation_notes.html#nVidia
> 
> Though I noted that it has been updated similar to your recommendation
> in other places now, including the nVidia forums:
> 
> http://www.nvnews.net/vbulletin/showthread.php?t=68681

I did discuss this with Max at fedorafaq and I thought he was going to 
update it after he tried it himself. I believe there's a similar issue 
with ATI drivers but neither of us have these so we can't test things 
for ourselves.

Unfortunately the advice on the nvidia forum suggests using just "chcon" 
to change the contexts, so the fix might not survive a relabel (I'm not 
sure if customizable types get changed during a relabel). Using semanage 
and restorecon should certainly be robust though.

> 
>> Undo it with:
>> # setsebool -P allow_execstack 0
>> # setsebool -P allow_execmod 0
>>
>> Then fix the file contexts instead:
>>
>> # semanage fcontext -a -f -- -t textrel_shlib_t 
>> '/usr/lib/libGL(core)?\.so(\.[^/]*)*'
>> # semanage fcontext -a -f -- -t textrel_shlib_t
>> '/usr/lib/libnvidia.*\.so(\.[^/]*)*'
>> # restorecon -v /usr/lib/libGL* /usr/lib/libnvidia*
>>
>> Please check that these files have context type textrel_shlib_t after 
>> doing this.
> 
> 
> # ls -lZ /usr/lib/libGL*
> lrwxrwxrwx  root root root:object_r:lib_t              /usr/lib/libGLcore.so.1 -> libGLcore.so.1.0.8762
> -rwxr-xr-x  root root system_u:object_r:textrel_shlib_t /usr/lib/libGLcore.so.1.0.8762
> -rw-r--r--  root root root:object_r:lib_t              /usr/lib/libGL.la
> lrwxrwxrwx  root root root:object_r:lib_t              /usr/lib/libGL.so -> libGL.so.1
> lrwxrwxrwx  root root root:object_r:lib_t              /usr/lib/libGL.so.1 -> libGL.so.1.0.8762
> -rwxr-xr-x  root root system_u:object_r:textrel_shlib_t /usr/lib/libGL.so.1.0.8762
> lrwxrwxrwx  root root system_u:object_r:lib_t          /usr/lib/libGLU.so -> libGLU.so.1
> lrwxrwxrwx  root root system_u:object_r:lib_t          /usr/lib/libGLU.so.1 -> libGLU.so.1.3.060402
> -rwxr-xr-x  root root system_u:object_r:textrel_shlib_t /usr/lib/libGLU.so.1.3.060402
> lrwxrwxrwx  root root system_u:object_r:lib_t          /usr/lib/libGLw.so -> libGLw.so.1
> lrwxrwxrwx  root root system_u:object_r:lib_t          /usr/lib/libGLw.so.1 -> libGLw.so.1.0.0
> -rwxr-xr-x  root root system_u:object_r:lib_t          /usr/lib/libGLw.so.1.0.0
> 
> 
> 
> # ls -lZ /usr/lib/libnvidia*
> lrwxrwxrwx  root root root:object_r:lib_t              /usr/lib/libnvidia-cfg.so -> libnvidia-cfg.so.1
> lrwxrwxrwx  root root root:object_r:lib_t              /usr/lib/libnvidia-cfg.so.1 -> libnvidia-cfg.so.1.0.8762
> -rwxr-xr-x  root root system_u:object_r:textrel_shlib_t /usr/lib/libnvidia-cfg.so.1.0.8762
> lrwxrwxrwx  root root root:object_r:lib_t              /usr/lib/libnvidia-tls.so.1 -> libnvidia-tls.so.1.0.8762
> -rwxr-xr-x  root root system_u:object_r:textrel_shlib_t /usr/lib/libnvidia-tls.so.1.0.8762

That looks OK then.

> So far, no more avc's, but I'll keep track overnight and through a
> couple of re-boots tomorrow.

Looks like it'll be time to switch back to enforcing mode soon then.

Paul.