Trying SELinux again on CentOS 5.1 - not quite HOPELESS

Tue Mar 4 08:10:51 UTC 2008

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?!?!?

> 
>> 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.

>> 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.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.