On Mon, 2008-03-03 at 21:34 -0600, Robert Nichols wrote: > 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. sounds like you want 2 rules allow dhcpc_t named_t:process ptrace dontaudit dhcpc_t *:process ptrace never tried it, but I think that will take care of it. dhcpc_t will be able to only troll around in the correct /proc directories and your logs will be empty from all the denials. > 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 Its no grephistory that is confined. The program that called it was running as innd_t and so when it called grephistory it continued to run in the innd_t domain. /me knows nothing about the news stuff, but this sounds like something that needs to be fixed with labeling rather than allow rules. The issue is that (and I'm just guessing here) /var/local/suck is not the standard place innd needs to write. Since you changed where it needs to write you need to make sure those files are labeled the way they needs to be to accept writes rather than the generic default fallback var_t. I have no idea what innd_t is supposed to be able to write to, but lets assume there are types which fit (aka run matchpathcon against a path name you know it is able to write to). Then do something like "semanage fcontext -a -t [insert type] "/var/local/suck(/.*)?" followed by restorecon -R -v /var/local/suck. Viola, no custom policy, just telling it how things need to be labeled. > 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 /me leaves this one for Dan to look at in the morning. some of it looks like a simple bug dan needs to fix in policy and isn't your fault (aka the cupsd_t -> hplip_exec_t stuff) but the right way to fix the hald_t -> cups issue I'm not sure of and we should leave that to the policy expert. > 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 remember, its not that pidof is being locked away without parole, its that dhcpc_t is being locked away. 2 options really: open up dhcpc_t policy with audit2allow -a/rinse/repeat (or do it in permissive one time rather than rinse repeat which you seem to have discovered) or add a new transition so that dhcpc_t can run pidof in an unconfined domain. I'm sure Dan will give details on this when he wakes up. > 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 Hmmmm, both of these are an issue with your having proc mounted inside the named chroot, why klogd is looking at the /proc/kmsg inside the chroot I have no idea. I thought that labeling for /proc would be correct even with strange mount points, I'll have to think about this when I get up in the morning. It is almost midnight here. > The phrase, "Not ready for prime time" comes to mind. I think we both agree you have the dhcp client do some pretty damn extraordinary things and no access control system is going to allow all of this out of the box. Somce things we can still fix easily (dontaudit and labeling for innd_t) and some things that I'm not sure what's wrong but I'm not the policy guru. Just remember you are trying to make dhcpc_t do things it was absolutely not designed to do. While I'll admit coming at this with no experience may make it seem daunting I'm sure you'll agree that most of the issues can be solved with little trouble. (I wish I could say all, but I don't even know the solution to all of them without a little playing a dabbling) as a sidebar, you might consider adding an audit rule like auditctl -a exit,always -S kill -F pid=1 this will add audit syscall overhead (which maybe be an issue if you box can't handle a bit more load) but will give you 'better' path names and such in your denial messages so you don't usually have to hunt down things like inode numbers.... -Eric -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
