targeted policy clashes CGI program under apache

[Ben]

I'm attempted to use the latest targeted policy under FC3, and while it 
generally works well, we're running into some problems when it comes 
time to pipe data from PHP into a complex CGI we have. The error we see 
is this:

Mar 21 22:17:11 blingbling kernel: audit(1111472231.280:0): avc:  
denied  { getsched } for  pid=405 exe=/var/www/test/cgi-bin/clip 
scontext=user_u:system_r:httpd_sys_script_t 
tcontext=user_u:system_r:httpd_sys_script_t tclass=process

Apache's error log shows this:

GThread-ERROR **: file gthread-posix.c: line 135 (): error 'Operation 
not permitted' during 'pthread_getschedparam (pthread_self(), &policy, 
&sched)'aborting...

My CGI does use glib threads; is that a bad thing?

I would like to use SELinux, but there's "like" and "need", and
right 
now I need to get this working. So, if there's no quick fix, is there a 
way to disable SELinux on just this one CGI, do I have to disable it 
for all of apache?

[Christofer C. Bell]

On Mon, 21 Mar 2005 23:13:42 -0800, Ben <bench(a)silentmedia.com&gt; wrote:
>  I would like to use SELinux, but there's "like" and
> "need", and right
>  now I need to get this working. So, if there's no quick fix, is there a
>  way to disable SELinux on just this one CGI, do I have to disable it
>  for all of apache? 
Look into audit2allow(8).  While using this tool to get your CGI
working will remove the same protection on other CGI scripts, you'll
be able to maintain some modicum of SELinux protection other than what
you're turning off to get this working.  Even if your final result is
"less secure" than running the full policy, it will be "more secure"
than disabling SELinux entirely.

-- 
Chris

"Build a man a fire and he will be warm for the rest of the night.  Set
a man on fire and he will be warm for the rest of his life."  -- Unknown

[Colin Walters]

On Mon, 2005-03-21 at 23:13 -0800, Ben wrote:

>  My CGI does use glib threads; is that a bad thing? 
Not a bad thing.  I think the CGI script policy author hadn't tested
multi-threaded scripts.

>  I would like to use SELinux, but there's "like" and
> "need", and right 
>  now I need to get this working. So, if there's no quick fix, is there a 
>  way to disable SELinux on just this one CGI, do I have to disable it 
>  for all of apache? 
You have three options basically:

1) Disable enforcement for Apache
2) Install policy source and add the permission
3) Wait for a FC3 policy update with this fixed

One thing that we had recently discussed doing is adding a
httpd_sys_script_unconfined_exec_t type, which when executed by httpd_t
would cause a transition to unconfined_t (i.e. not be confined by
SELinux).  But I don't think this is done yet.

For 1), see the Fedora SELinux FAQ.
For 2, see:

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide...

Or:
http://fedora.redhat.com/docs/selinux-apache-fc3/sn-debugging-and-customi...

The major caveats with maintaining your own modified policy in this
fashion at the moment are that you have to know about using "make" etc.
to build it, and it's somewhat fragile with respect to upgrades.

Upstream SELinux work is going to make it a lot easier to create and
maintain policy changes from a binary policy.

[Ben]

On Mar 22, 2005, at 5:44 AM, Colin Walters wrote:

>  You have three options basically:
>
>  1) Disable enforcement for Apache
>  2) Install policy source and add the permission
>  3) Wait for a FC3 policy update with this fixed 
Well, thanks to audit2allow, it looks like 2 will be pretty easy. I'm 
worried about what you mean when you say it makes updates fragile, 
however...... what do you mean?

[Colin Walters]

On Tue, 2005-03-22 at 08:25 -0800, Ben wrote:
>  On Mar 22, 2005, at 5:44 AM, Colin Walters wrote:
>  
>  > You have three options basically:
>  >
>  > 1) Disable enforcement for Apache
>  > 2) Install policy source and add the permission
>  > 3) Wait for a FC3 policy update with this fixed
>  
>  Well, thanks to audit2allow, it looks like 2 will be pretty easy. I'm 
>  worried about what you mean when you say it makes updates fragile, 
>  however...... what do you mean? 
It should generally work if all you're doing is adding a local.te with a
few additional policy rules.  I do it myself on my server.