Marc Schwartz (via MN) wrote:
On Wed, 2006-06-21 at 15:43 +0100, Paul Howarth wrote:
Marc Schwartz (via MN) wrote:
On Wed, 2006-06-21 at 08:20 +0100, Paul Howarth wrote:
OK, here's an updated version of mypyzor.te:
policy_module(mypyzor, 0.1.3)
require {
type pyzor_t;
type pyzor_exec_t;
type pyzor_port_t;
type spamd_t;
};
# temp files
type pyzor_tmp_t;
files_tmp_file(pyzor_tmp_t)
# Allow pyzor to create and use temp files and dirs
allow pyzor_t pyzor_tmp_t:dir create_dir_perms;
allow pyzor_t pyzor_tmp_t:file create_file_perms;
files_type(pyzor_tmp_t)
files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir })
# Allow pyzor to read config (and any other file...)
# from user home directories
userdom_read_unpriv_users_home_content_files(pyzor_t)
# Allow pyzor to read /dev/urandom
dev_read_urand(pyzor_t)
# Allow pyzor to send and receive pyzor messages!
allow pyzor_t pyzor_port_t:udp_socket send_msg;
allow pyzor_t pyzor_port_t:udp_socket recv_msg;
# Allow spamd to signal pyzor (kill/hup ?)
allow spamd_t pyzor_t:process signal;
# This doesn't seem to break anything
dontaudit spamd_t pyzor_exec_t:file getattr;
# Allow pyzor to ...?
corecmd_search_bin(pyzor_t)
kernel_read_kernel_sysctls(pyzor_t)
# It does a getattr on /usr/bin/time for reasons unknown...
# Would be nice to know if changing these from
# allow to dontaudit causes any breakage
allow pyzor_t bin_t:dir getattr;
allow pyzor_t bin_t:file getattr;
# Pyzor/python probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(pyzor_t)
kernel_dontaudit_read_system_state(pyzor_t)
Paul,
I have made the change and all seems well so far.
Note that the version you have above is the same as the prior version.
So I bumped it 0.2.0 arbitrarily, unless you have an alternative
versioning schema that you want to stay with.
Whoops. I've updated my copy now so we should stay in sync. Could you
try bumping the version again and removing these lines:
allow pyzor_t bin_t:dir getattr;
allow pyzor_t bin_t:file getattr;
I'd like to see if things still work. If so, we can dontaudit these
instead of allowing them.
Similarly, can you try removing the mypostfix module (semodule -r
mypostfix) and see if things still work? The strange AVC of
postfix_master_t reading the manpage should reappear and it would be
interesting to see if it broke in some way in enforcing mode.
OK. Commented out the above lines in mypyzor.te (v 0.2.1) and removed
mypostfix.
The current modules then are:
# semodule -l
amavis 1.0.4
clamav 1.0.1
myclamscan 0.2.0
mydcc 0.1.3
mypyzor 0.2.1
procmail 0.5.3
pyzor 1.0.1
No msgs are being reported by avclist subsequent to the above changes.
Specifically nothing wrt the postfix manpage weirdness.
All else appears to be OK so far.
Can you try restarting postfix? I think the manpage thing happened at
that point.
Once that's done I'd like to try out the dcc and razor modules that are
now in rawhide. That will involve going back to permissive mode for a
while though.
Paul.
Paul.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
