Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=480129
--- Comment #7 from Erik M Jacobs <ejacobs(a)redhat.com> 2012-03-31 18:47:31 EDT ---
So the violation is because of a read shadow restraint. Since I can't think of
a good reason why amavisd should be reading shadow, I just commented it out.
[root@atlas ~]$ cat amavisd.te
module amavisd 1.0;
require {
type amavis_t;
type security_t;
type proc_t;
type user_home_dir_t;
type selinux_config_t;
#type shadow_t;
class file { read getattr };
class dir search;
}
#============= amavis_t ==============
allow amavis_t proc_t:file read;
allow amavis_t security_t:dir search;
allow amavis_t security_t:file read;
allow amavis_t selinux_config_t:dir search;
allow amavis_t selinux_config_t:file { read getattr };
#allow amavis_t shadow_t:file { read getattr };
allow amavis_t user_home_dir_t:dir search;
Installing this module works, and when in enforcing mode, no error is
generated:
[root@atlas ~]$ getenforce
Enforcing
[root@atlas ~]$ service amavisd restart
Shutting down amavisd: Daemon [3347] terminated by SIGTERM
[ OK ]
amavisd stopped
Starting amavisd: [ OK ]
The only selinux denial that still happens is the shadow read:
[root@atlas ~]$ ausearch -m avc -ts 22:45:50 | audit2allow
#============= amavis_t ==============
allow amavis_t shadow_t:file read;
Now, this policy module can probably be clamped down to fix what's going on,
because it seems to me like it opens up a fair number of holes.
--
Configure bugmail:
https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.