Arthur Pemberton wrote:
On Mon, Mar 3, 2008 at 6:25 PM, Robert Nichols
<rnicholsNOSPAM@xxxxxxxxxxx> wrote:
Daniel J Walsh wrote:
> Simplest thing is to run this through
> # grep avc /var/log/audit2allow | audit2allow -M mypol
> # semodule -i mypol.pp
>
>
> You might want to first update to the U2 preview policy, available on
> http://people.redhat.com/dwalsh/SELinux/RHEL5
This is turning into a worse disaster than I would have imagined.
I have SELinux running in targeted mode on two machines with Centos5
without issue. What exactly is the problem you are having?
You really want to know?? OK, there's probably enough here to get
me banned from the list, but here it comes ... :
1) The bulk of the AVCs are coming from 'pidof' running in context
system_u:system_r:dhcpc_t needing "ptrace" capability for every
tcontext that might show up in /proc. audit2allow is NOT the
solution for that. Apart from the problem of individually allowing
every possible tcontext, allowing "ptrace" for just any process
that might be running with that scontext would be a big security
hole.
2) Here is what happened when the news fetch started. This looks
like the classic problem of using shell I/O redirection to do the
unthinkable and send the output from a command to a file. Why
someone thought that 'grephistory' needed to be restricted is
totally unfathomable to me:
avc: denied { write } for pid=6305 comm="grephistory" path="/var/local/suck/suck.new-ids" dev=hda6 ino=189277
scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:object_r:var_t:s0 tclass=file
avc: denied { read write } for pid=6305 comm="grephistory" path="socket:[63191]" dev=sockfs ino=63191
scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=tcp_socket
avc: denied { getattr } for pid=6305 comm="grephistory" path="/var/local/suck/suck.new-ids" dev=hda6 ino=189277
scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:object_r:var_t:s0 tclass=file
3) Here are the complaints resulting from running "enscript -f
Courier9 /etc/dhclient-exit-hooks" (output going to an HP printer).
I have no idea what the problem is here, but it looks major:
avc: denied { getattr } for pid=6927 comm="python" path="/var/run/cups/cups.sock" dev=hda6 ino=283435
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=sock_file
avc: denied { read } for pid=6927 comm="python" name="random" dev=tmpfs ino=2188 scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file
avc: denied { write } for pid=6927 comm="python" name="cups.sock" dev=hda6 ino=283435
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=sock_file
avc: denied { connectto } for pid=6927 comm="python" path="/var/run/cups/cups.sock"
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tclass=unix_stream_socket
avc: denied { read } for pid=6927 comm="python" name="0" dev=hda6 ino=283436 scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=file
avc: denied { getattr } for pid=6927 comm="python" path="/var/run/cups/certs/0" dev=hda6 ino=283436
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=file
avc: denied { getattr } for pid=6955 comm="sh" path="/usr/bin/hpijs" dev=hda5 ino=65915
scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file
avc: denied { execute } for pid=6955 comm="sh" name="hpijs" dev=hda5 ino=65915
scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file
avc: denied { read } for pid=6955 comm="sh" name="hpijs" dev=hda5 ino=65915
scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file
avc: denied { execute_no_trans } for pid=6955 comm="sh" path="/usr/bin/hpijs" dev=hda5 ino=65915
scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file
4) Oh yes, some mail arrived around this time. Here are the complaints
from procmail. Someone apparently feels that 'pidof' should be locked
away for life without parole.
avc: denied { read } for pid=5231 comm="pidof" name="stat" dev=proc ino=217317389
scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=file
avc: denied { getattr } for pid=5231 comm="pidof" path="/proc/3316/stat" dev=proc ino=217317389
scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=file
5) There are also a bunch of AVCs that occur during system boot and shutdown.
For example, here are a couple that come up during boot. Now of course
'klogd' should be denied read permission for /proc/kmesg -- that is just
_such_ an _evil_ thing for it to be doing! As for mcstransd, looks like
it found it's way down into /var/named/chroot/proc and obviously couldn't
be trusted there.
avc: denied { read } for pid=2747 comm="klogd" path="/proc/kmsg" dev=proc ino=-268435447
scontext=system_u:system_r:klogd_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=file
avc: denied { search } for pid=2768 comm="mcstransd" name="/" dev=proc ino=1
scontext=system_u:system_r:setrans_t:s0-s0:c0.c1023 tcontext=system_u:object_r:named_conf_t:s0 tclass=dir
The phrase, "Not ready for prime time" comes to mind.
I am simply not prepared to go through sorting out these sorts of problems
every time I do something that isn't an exact repeat of something I've
done before and fought through the problems that came up. So, shut it
off and geridduvit.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
