Denial Msg - apache, mogrify, perl, cgi, postgres, setenforce delay

[Dominick Grift]

On Sun, 2009-11-22 at 10:39 -0600, Jonathan Hoover wrote:
> Hello all,
>  
> One of our developers has a fairly simple script that uploads an image
> to a server, via a cgi perl script. The box is Fedora 11, all up to
> date. He is using the CGI and the File::Basename perl modules. He is
> also using mogrify from the ImageMagick package to change the width of
> the uploaded file, and save it as a thumbnail. This is called in perl
> via system("mogrify $args"). This seems to succeed, as the thumbnail
> file is created and valid. Finally, a record is added to a postgresql
> database.
>  
> What's puzzling is that with SELinux in permissive mode, all goes as
> expected, with the following messages logged. With it set to
> enforcing, though, we get an error from postgresql about more
> expressions than target columns, with what appears to be the
> filehandle to the image.
>  
> >From /var/log/messages:
> Nov 22 10:16:02 kilby setroubleshoot: SELinux is preventing mogrify
> (httpd_sys_script_t) "getsched" httpd_sys_script_t. For complete
> SELinux messages. run sealert -l 201e87d5-7250-4a96-a3ab-6b148b40f206
> 
> >From /var/log/audit/audit.log, these two:
> type=AVC msg=audit(1258906560.216:220051): avc:  denied  { getsched }
> for  pid=31641 comm="mogrify"
> scontext=unconfined_u:system_r:httpd_sys_script_t:s0
> tcontext=unconfined_u:system_r:httpd_sys_script_t:s0 tclass=process
> 
> type=SYSCALL msg=audit(1258906560.216:220051): arch=40000003
> syscall=242 success=no exit=-13 a0=7b99 a1=80 a2=bfe5a490 a3=80
> items=0 ppid=31638 pid=31641 auid=0 uid=48 gid=48 euid=48 suid=48
> fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=433 comm="mogrify"
> exe="/usr/bin/mogrify"
> subj=unconfined_u:system_r:httpd_sys_script_t:s0 key=(null)
> 
> >From my apache.err.log, only when SELinux is set to enforcing:
> [Sat Nov 21 17:08:27 2009] [error] [client 64.198.x.x] DBD::Pg::st
> execute failed: ERROR:  INSERT has more expressions than target
> columns at /www/website/htdocs/modules//dbfunc.pl line 23,
> <fh00001testpicture.jpg> line 192., referer:
> http://64.198.x.x/add-listing.cgi
> 
> So, a few questions:
>  
> 1. I notice a somewhat random delay of 10 to 30 minutes before the
> script works after a "setenforce 0". Likewise, it takes some amount of
> time after a "setenforce 1" before the script breaks. Is there
> supposed to be a delay? This makes troubleshooting very difficult,
> because you don't really know if it's enforcing yet or not. I noticed
> this message in /var/log/messages, and thought it might be related to
> the delay: Nov 22 09:57:33 kilby dbus: Can't send to audit system:
> USER_AVC avc:  received setenforce notice (enforcing=1)#012:
> exe="?" (sauid=81, hostname=?, addr=?, terminal=?)

The delay is (likely) not SELinux related no. The message reflects a bug
in dbus and this is unrelated and not harmful.

> 2. What is the "getsched" action that mogrify is attempting?

get schedule i believe. It is a permission. "The getpriority,
sched_getscheduler, and sched_getparam calls are controlled using the
getsched permission."

> 3. Why the httpd_sys_script_t context?

This is the confined environment for apache (default) system scripts.
files in /var/www/cgi-bin.

> 4. Should the file upload and mogrify be creating files with a
> httpd_sys_content_rw_t context? The "rw" read/write part I was a
> little concerned by.

Yes the confined apache system environment is allowed to only create
objects in locations labelled httpd_sys_content_rw_t and files created
there automatically inherit the type of the parent location.

> 5. Any idea why this is throwing a postgres error? I would have
> expected the mogrify to not work given the error messages
> in /var/log/messages and /var/log/audit/audit.log - but that works
> just fine. Plus, the INSERT seems to be just fine actually, as I have
> the developer spitting that out in the page that is returned.

I guess mogrify could not do its job good enough (if at all) for
postgresql to accept it due to the getsched permission missing.

You could decide you modify the sys script environment to allow the
getsched permission or you could distribute your webapp with a
customized tailor made policy (environment/domain) module for the
script. This way consumers will not have to alter existing
environments/domains, but they will be required to install the policy
module that you have included with your distribution.

Since your webapp is required to create objects, your consumers will
have to configure SELinux to allow it to be able to do so without a
custom module as well.

By including a custom policy you can take care of both policy and
labeling for them.

> Thanks in advance,
> Jon
> --
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list