Trying SELinux again on CentOS 5.1 - not quite HOPELESS

Tue Mar 4 04:48:05 UTC 2008

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 at comcast.net> 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