-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert Nichols wrote:
> Eric Paris wrote:
>> On Mon, 2008-03-03 at 21:34 -0600, Robert Nichols wrote:
>>> 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.
>
> The program that called grephistory was running from root's crontab. No
> way
> was that running as innd_t. Perhaps grephistory transitioned to that
> domain to ensure access to the innd database. I guess I could make that
> file news_spool_t, or just create it somewhere in the news spool, where
> innd
> normally operates. That still leaves the 2nd AVC, path="socket[63191]".
> I have no idea what that socket is for. OK, I just ran an strace on
> grephistory, and the only socket it uses is to /dev/log. What, innd_t
> isn't
> allowed to talk to syslogd?!?!?
>
NO this is a leaked file descriptor. You have a process running
unconfined_t that is transitioning to innd_t and leaking an open file
descriptor to innd_t. Without SELinux innd_t would be able to
communicate on this open tcp_socket. SELinux closes the descriptor and
reports the AVC.
>>
>>> 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.
>
> Could still be my fault. I'm running hplip-1.7.4a-3.fc6, not the older
> version that's in CentOS 5.1 (which doesn't support my printer), but FC6
> was the basis for RHEL5/CentOS-5.
>
These are in Rawhide and Fedora 8 policy so I will add them to RHEL5.2
policy
domtrans_pattern(cupsd_t,hplip_exec_t, hplip_t)
domtrans_pattern(cupsd_config_t,hplip_exec_t, hplip_t)
>>> 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.
>
> That's a non-issue, then. Somehow I missed the "named_conf_t" on that
> first AVC. If I had SELinux running in enforcing mode, there would be
> no need to run named chroot-ed.
>
>>> 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....
>
> Thanks, Eric. That's a bit more encouraging. I'm going to give this a
> rest for a week or so. Right now I've restored my system back to the
> way it was before I started experimenting.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkfNZGgACgkQrlYvE4MpobO1MgCgjJPbXGV26MkDg1OaduAzERt3
eX0An1yr40QV6Oy0VCqDQ1AsKZkXYRUf
=UPMW
-----END PGP SIGNATURE-----
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
