postfix, procmail and SELinux - No Go
Marc Schwartz (via MN)
mschwartz at mn.rr.com
Tue Jul 18 14:53:27 UTC 2006
On Tue, 2006-07-18 at 14:11 +0100, Paul Howarth wrote:
> Marc Schwartz (via MN) wrote:
> > Latest avc's below, subsequent to the updates and reboots. I have tried
> > to remove a lot of the dups. If you need more info, let me know.
> >
> > Marc
<snip>
> > type=AVC msg=audit(1153030201.398:2924): avc: denied { read } for pid=11167 comm="restorecon" name="[220111]" dev=pipefs ino=2201 11 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file
> > type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167 comm="restorecon" name="[220112]" dev=pipefs ino=220 112 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file
> > type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167 comm="restorecon" name="[220112]" dev=pipefs ino=220 112 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file
> > type=SYSCALL msg=audit(1153030201.398:2924): arch=40000003 syscall=11 success=yes exit=0 a0=89ad188 a1=89ad320 a2=89ad258 a3=89acfc0 items=2 pid=11167 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon" exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0
> > type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]"
> > type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]"
> > type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220111]"
> > type=CWD msg=audit(1153030201.398:2924): cwd="/"
> > type=PATH msg=audit(1153030201.398:2924): item=0 name="/sbin/restorecon" inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00 obj=system_u:object_r:restorecon_exec_t:s0
> > type=PATH msg=audit(1153030201.398:2924): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:ld_so_t:s0
> > type=AVC msg=audit(1153030201.414:2925): avc: denied { sigchld } for pid=11161 comm="crond" scontext=user_u:system_r:restorecon_t :s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process
> > type=SYSCALL msg=audit(1153030201.414:2925): arch=40000003 syscall=114 success=no exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11161 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond" exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255
> > type=AVC msg=audit(1153030261.495:2940): avc: denied { read } for pid=11202 comm="restorecon" name="[220497]" dev=pipefs ino=2204 97 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file
> > type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202 comm="restorecon" name="[220498]" dev=pipefs ino=220 498 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file
> > type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202 comm="restorecon" name="[220498]" dev=pipefs ino=220 498 scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file
> > type=AVC msg=audit(1153030261.515:2941): avc: denied { sigchld } for pid=11201 comm="crond" scontext=user_u:system_r:restorecon_t :s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process
> > type=SYSCALL msg=audit(1153030261.515:2941): arch=40000003 syscall=114 success=no exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11201 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond" exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255
> > type=SYSCALL msg=audit(1153030261.495:2940): arch=40000003 syscall=11 success=yes exit=0 a0=84d91a0 a1=84d9340 a2=84d9278 a3=84d8fb8 items=2 pid=11202 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon" exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0
> > type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]"
> > type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]"
> > type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220497]"
> > type=CWD msg=audit(1153030261.495:2940): cwd="/"
> > type=PATH msg=audit(1153030261.495:2940): item=0 name="/sbin/restorecon" inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00 obj=system_u:object_r:restorecon_exec_t:s0
> > type=PATH msg=audit(1153030261.495:2940): item=1 name=(null) inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:ld_so_t:s0
>
> These all appear to be due to running restorecon in a cron job. Probably
> your dcc client building script.
Yep:
# 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?
>
> > 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.
I re-ran it just in case something changed after I re-built the driver
with the latest kernel install (2157). I'll keep an eye out for any
further avc's.
I appreciate the caveats noted on the page you reference.
> > 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
> ::::::::::::::
> myspamassassin.te
> ::::::::::::::
> policy_module(myspamassassin, 0.1.5)
>
> require {
> type spamd_t;
> }
>
> type spamd_log_t;
> logging_log_file(spamd_log_t)
>
> # These appear to be in selinux-policy-2.2.47-3.fc5
> # but don't seem to be working. Perhaps they need to be
> # included in the base policy rather than as separate modules?
> dcc_domtrans_client(spamd_t)
> pyzor_domtrans(spamd_t)
>
> # Signal the dcc client (SIGTERM is used?)
> dcc_signal_client(spamd_t)
>
> # Use log files
> allow spamd_t spamd_log_t:file create_file_perms;
> allow spamd_t spamd_log_t:dir rw_dir_perms;
> logging_log_filetrans(spamd_t,spamd_log_t,{ file dir })
All changed.
I'll post back with any new avc's after a bit and a re-boot or two.
Thanks,
Marc
More information about the fedora-selinux-list
mailing list