[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: postfix, procmail and SELinux - No Go



On Tue, 2006-07-18 at 16:15 +0100, Paul Howarth wrote:
> Marc Schwartz (via MN) wrote:
> > On Tue, 2006-07-18 at 14:11 +0100, Paul Howarth wrote:
> > # Run restorecon to restore the SELinux context after re-building
> > 10 01 * * * root /sbin/restorecon -rv /var/dcc
> > 11 01 * * * root /sbin/restorecon -v /usr/local/bin/dccproc
> > 
> > 
> >> I could add this to the dcc policy (or a separate local module for 
> >> restorecon):
> >> cron_system_entry(restorecon_t)
> >>
> >> However, I think that the "right" way to fix this would be to use 
> >> restorecond and add an entry to /etc/selinux/restorecond.conf (the 
> >> manpage for restorecond suggests 
> >> /etc/selinux/POLICYTYPE/restorconfiles.conf but that file doesn't seem 
> >> to exist, and the restorecond binary includes the string 
> >> /etc/selinux/restorecond.conf).
> >>
> >> Maybe Dan could comment on that?
> 
> Try this instead of your cron jobs and see what happens:
> 
> # chkconfig --add restorecond
> # chkconfig restorecond on
> 
> Edit /etc/selinux/restorecond.conf and add a line:
> 
> /usr/local/bin/dccproc

All the above done.

> (is the restorecon of /var/dcc actually needed?)

Hopefully not.  We did that as a temp fix b/c the context would change
after each nightly build.

> If you have network-mounted home directories, you may want to remove the 
> lines starting with "~"
> 
> Then:
> # service restorecond start

Done.

> >>> 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

> 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


> The upstream policy has file contexts set for this but I fear they're 
> falling foul of the file contexts ordering rules.
> 
> >>> type=PATH msg=audit(1153138559.711:8): item=0 name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0
> >>> type=AVC msg=audit(1153138559.715:9): avc:  denied  { read } for  pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 scontext=s ystem_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file
> >>> type=SYSCALL msg=audit(1153138559.715:9): arch=40000003 syscall=5 success=no exit=-13 a0=48909fd4 a1=0 a2=804a000 a3=48909fda items= 1 pid=2374 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty" exe="/sbin/mingetty" s ubj=system_u:system_r:getty_t:s0
> >>> type=CWD msg=audit(1153138559.715:9):  cwd="/"
> >>> type=PATH msg=audit(1153138559.715:9): item=0 name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0
> >>> type=AVC msg=audit(1153138559.715:10): avc:  denied  { read write } for  pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 sco ntext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file
> >>> type=SYSCALL msg=audit(1153138559.715:10): arch=40000003 syscall=5 success=no exit=-13 a0=48909fd4 a1=2 a2=0 a3=48909fda items=1 pid =2374 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty" exe="/sbin/mingetty" subj=s ystem_u:system_r:getty_t:s0
> >>> type=CWD msg=audit(1153138559.715:10):  cwd="/"
> >> Your /var/run/utmp appears to be labelled init_var_run_t rather than 
> >> initrc_var_run_t.
> > 
> > Yep:
> > 
> > # ls -lZ /var/run/utmp
> > -rw-rw-r--  root utmp system_u:object_r:init_var_run_t /var/run/utmp
> > 
> > # restorecon /var/run/utmp
> > 
> > # ls -lZ /var/run/utmp
> > -rw-rw-r--  root utmp system_u:object_r:initrc_var_run_t /var/run/utmp
> 
> Running restorecond should stop this happening again.
> 
> Paul.

OK. All done.

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

Thanks,

Marc



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]