Trying SELinux again on CentOS 5.1 - not quite HOPELESS

Tue Mar 4 14:52:32 UTC 2008

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Paris wrote:
> 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

Using interfaces this will probably work.

ps_process_pattern(dhcpc_t, named_t)
domain_dontaudit_ptrace_all_domains(dhcpc_t)
domain_dontaudit_read_all_domains_state(dhcpc_t)
> 
> 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.
> 

# semanage fcontext -a -t innd_var_run_t /var/local/suck(/.*)?
# restorecon -R -v /var/local/suck

Or better yet move this file to /var/run/innd or /var/lib/news

>> 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
>
This would either involve writing your own policy of sucking in the hal
and cups policy from Fedora.

> /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
> 
THese are the same bugs as above and the dontaudit interfaces would
remove it.  This is just a matter of dhcpc_t trying to read all processes.

> 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
> 
THese are bugs in named-chroot.  You can also turn off msctransd as it
does very little for you.
> 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
> 
Robert,

As Eric said the policy changes you want are not going to be fixed in
Fedora 9/10/11.  They are caused by you running a lots of additional
applications that a confined domain is not expected to run.  We can know
all possible code paths for what people are going to do, and if you
believe SELinux is not ready for prime time, that is fine.  We have the
flexibilty to work though all of your avc messages and customize the
policy, but if you decide you don't want the headache then turn it off.

SELinux is attempting to confine potentially dangerous applications like
dhcp which listens to untrusted content on the wire and executes as
root.  We try to design the policy as flexible as possible, but in a
customized environment like yours, it will fail, with out a decent
amount of policy writing.
> --
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfNYjAACgkQrlYvE4MpobMo7wCg5H1eEPjB3n7q5LwBoB+Ew4QB
qswAoKNcEjUecDYJZsHZV2cjrCdF4y9Z
=6DNE
-----END PGP SIGNATURE-----