search for: clamscan_t

...y problem with generating a custom policy consisting of the > following? > > grep avc /var/log/audit/audit.log | audit2allow > > > #============= amavis_t ============== > allow amavis_t shell_exec_t:file execute; > allow amavis_t sysfs_t:dir search; > > #============= clamscan_t ============== > allow clamscan_t amavis_spool_t:dir read; In the latest rhel6 policies amavas_t and clamscan_t have been merged into antivirus_t? Is you selinux-policy up 2 date? > #============= logwatch_mail_t ============== > allow logwatch_mail_t usr_t:lnk_file read; > > #=====...

...mp/amavis-20120930T154701-14709/parts/p001: OK" Here is an SE Linux failure message: Sep 30 15:54:53 (null) (null): audit(1349013293.978:90934): avc: denied { remove_name } for pid=19832 comm=clamscan name=clamav-9e9d055254e79e18d8f8592eeee57a53 ino=655768 dev=dm-0 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:amavis_var_lib_t:s0 tclass=dir I had found two web pointer with this issue, but no solutions: Here is my solution, which is proposed to be inserted in Chapter 5: SELinux: * create file: --se_clamav_amavis.te-- # ***HaO 2012-09-30: add rule to allow clamav to access...

I am seeing these avc messages on a newly commissioned and up-to-date CentOs-6 virtual guest: ---- time->Thu Dec 4 12:14:58 2014 type=SYSCALL msg=audit(1417713298.610:60522): arch=c000003e syscall=2 success=no exit=-13 a0=7fd70e6de1e6 a1=0 a2=1b6 a3=0 items=0 ppid=2698 pid=4294 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2784 comm="trivial-rewrite"

...y consisting of the >> following? >> >> grep avc /var/log/audit/audit.log | audit2allow >> >> >> #============= amavis_t ============== >> allow amavis_t shell_exec_t:file execute; >> allow amavis_t sysfs_t:dir search; >> >> #============= clamscan_t ============== >> allow clamscan_t amavis_spool_t:dir read; > In the latest rhel6 policies amavas_t and clamscan_t have been merged > into antivirus_t? Is you selinux-policy up 2 date? Yes, everything is up-to-date as of the time of report and I have checked again this morning. That...

...cause I am looking for them more frequently but it seems to me that something has happened external to my control. The most recent things I see are these: audit2allow -l -a #============= amavis_t ============== allow amavis_t sysfs_t:dir read; allow amavis_t sysfs_t:file open; #============= clamscan_t ============== #!!!! The source type 'clamscan_t' can write to a 'dir' of the following types: # clamscan_tmp_t, clamd_var_lib_t, tmp_t, root_t allow clamscan_t amavis_spool_t:dir write; #============= postfix_smtp_t ============== allow postfix_smtp_t postfix_spool_maildrop_t:fil...

...d one if there is but. . . > Anyone see any problem with generating a custom policy consisting of the following? grep avc /var/log/audit/audit.log | audit2allow #============= amavis_t ============== allow amavis_t shell_exec_t:file execute; allow amavis_t sysfs_t:dir search; #============= clamscan_t ============== allow clamscan_t amavis_spool_t:dir read; #============= logwatch_mail_t ============== allow logwatch_mail_t usr_t:lnk_file read; #============= postfix_master_t ============== allow postfix_master_t tmp_t:dir read; #============= postfix_postdrop_t ============== allow postfix_p...