Horde Application Suite and SELinux...

[Tom Lisjac]

Hi folks!

I've just installed the php based Horde Application Suite
(http://horde.org) on a Fedora Core 3. Everything is working great
with the targeted policy and SELinux enabled except for a small
problem with spell checking in the Imp webmail app.

The spell checker passes the text to aspell using a temporary file in
/tmp. The targeted policy prohibits "http scripts" from using the /tmp
directory... so aspell runs but doesn't return any results. If I
disable SELinux, it works fine... but since this server will be
running in a hostile environment, I'd rather not.  I could also add:

allow httpd_sys_script_t httpd_tmp_t:file { getattr read };

... to the targeted policy, but I'd prefer not modify it or open this
directory up to other less trustworthy scripts that may eventually run
on the system.

I've thought about creating a separate directory and rule for this app
and operation... but I can't help but wonder if there's better
approach for resolving this problem? Any suggestions would be greatly
appreciated!

Thanks,

-Tom

[Colin Walters]

On Tue, 2005-02-22 at 14:14 -0700, Tom Lisjac wrote:
> Hi folks!
>
> I've just installed the php based Horde Application Suite
> (http://horde.org) on a Fedora Core 3. Everything is working great
> with the targeted policy and SELinux enabled except for a small
> problem with spell checking in the Imp webmail app.
>
> The spell checker passes the text to aspell using a temporary file in
> /tmp. The targeted policy prohibits "http scripts" from using the /tmp
> directory...  
CGI scripts (running as httpd_sys_script_t) shouldn't be prevented from
using /tmp; this macro in macros/apache_macros.te allows it:

file_type_auto_trans(httpd_$1_script_t, tmp_t, httpd_$1_script_rw_t)

> so aspell runs but doesn't return any results. If I
> disable SELinux, it works fine... but since this server will be
> running in a hostile environment, I'd rather not.  I could also add:
>
> allow httpd_sys_script_t httpd_tmp_t:file { getattr read }; 
Hmmm.  httpd_tmp_t is the type of temporary files generated by the main
webserver, not by CGI scripts.  Perhaps what's happening is you have
some PHP code which is using aspell and creating a temporary file in the
main httpd process, and then a CGI script wants to read that later?

Hard to say without knowing more details about how aspell works.

[Tom Lisjac]

On Tue, 22 Feb 2005 17:12:20 -0500, Colin Walters <walters(a)redhat.com&gt; wrote:
>  On Tue, 2005-02-22 at 14:14 -0700, Tom Lisjac wrote: 
Thanks for the reply.

>  >...so aspell runs but doesn't return any results. If I
>  >disable SELinux, it works fine... but since this server will be
>  >running in a hostile environment, I'd rather not.  I could also add:
>  >
>  >allow httpd_sys_script_t httpd_tmp_t:file { getattr read };
>  
>  Hmmm.  httpd_tmp_t is the type of temporary files generated by the main
>  webserver, not by CGI scripts.  Perhaps what's happening is you have
>  some PHP code which is using aspell and creating a temporary file in the
>  main httpd process, and then a CGI script wants to read that later? 
I was under the impression that mod_php and the webserver ran in the
same context... so I'm not sure I understand the distinction SELinux
would make between the server and the script.

Here's the avc that is generated. Apparently the write did occur and
this was an attempt by the script to read the spellchecked file back.

avc:  denied  { getattr } for  pid=32122 exe=/usr/bin/aspell
path=/tmp/spellkQimNQ dev=hda2 ino=326408
scontext=root:system_r:httpd_sys_script_t
tcontext=root:object_r:httpd_tmp_t tclass=file

I'm curious why the targeted policy allows the write but blocks reads from /tmp?

In any case, it appears that I should make the exception and allow the
read. I made a huge mess when I started hacking the policy sources in
FC2... is there a document or howto somewhere that describes the
correct way to add a exception that will survive an rpm policy update?

Thanks,

-Tom

[Karsten Wade]

On Tue, 2005-02-22 at 16:44 -0700, Tom Lisjac wrote:

>  In any case, it appears that I should make the exception and allow
> the
>  read. I made a huge mess when I started hacking the policy sources in
>  FC2... is there a document or howto somewhere that describes the
>  correct way to add a exception that will survive an rpm policy update? 
Short answer - /etc/selinux/targeted/src/policy/domains/misc/local.te.

Long answer - I tried to compile all the best recommendations here:

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

File a bug if you hear about one I'm missing. :)

- Karsten
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
               IT executives rate Red Hat #1 for value              
                 http://www.redhat.com/promo/vendor/

[Colin Walters]

On Tue, 2005-02-22 at 16:44 -0700, Tom Lisjac wrote:

> I was under the impression that mod_php and the webserver ran in the
> same context... so I'm not sure I understand the distinction SELinux
> would make between the server and the script. 
You are correct; mod_php code does run in the same context as Apache
(i.e. httpd_t), because it runs in-process.

> Here's the avc that is generated. Apparently the write did occur
> and
> this was an attempt by the script to read the spellchecked file back.
>
> avc:  denied  { getattr } for  pid=32122 exe=/usr/bin/aspell
> path=/tmp/spellkQimNQ dev=hda2 ino=326408
> scontext=root:system_r:httpd_sys_script_t
> tcontext=root:object_r:httpd_tmp_t tclass=file 
Note however here that the source context is httpd_sys_script_t (not
httpd_t), which means it's a CGI script.  CGI scripts by default run in
a separate context.  

Are you really sure that you don't have an external CGI script being
run?

Perhaps what is happening here is that for some reason, when httpd_t
execs /usr/bin/aspell, a transition is happening to httpd_sys_script_t.
But from looking at the policy, I don't see any transition rules for
bin_t.

> I'm curious why the targeted policy allows the write but blocks
> reads from /tmp? 
Because as best I can tell, the write was done by the main webserver
process, and the read is being attempted by a CGI script.

Consider the case where Apache keeps temporary data files containing
private information in /tmp; in general you don't want CGI scripts to be
able to read that.

> In any case, it appears that I should make the exception and allow
> the
> read. I made a huge mess when I started hacking the policy sources in
> FC2... is there a document or howto somewhere that describes the
> correct way to add a exception that will survive an rpm policy update? 
You should probably upgrade to FC3; a huge amount of work has gone into
the policy (but we still have a lot more to do...).

[Colin Walters]

On Wed, 2005-02-23 at 09:49 -0500, Colin Walters wrote:

> >In any case, it appears that I should make the exception and allow
> the
> >read. I made a huge mess when I started hacking the policy sources in
> >FC2... is there a document or howto somewhere that describes the
> >correct way to add a exception that will survive an rpm policy update? 
One other note - all my comments were relative to the rawhide targeted
policy (which in the case of httpd AFAIK isn't very divergent from FC3).
However I know the delta between FC2 and FC3 is larger, particularly due
to the strict->targeted transition, and it's quite possible there are
bugs there (such as the one you are encountering) which are fixed in
FC3.  Upgrading very strongly recommended :)

[Tom Lisjac]

On Wed, 23 Feb 2005 10:33:25 -0500, Colin Walters <walters(a)redhat.com&gt; wrote:
>  On Wed, 2005-02-23 at 09:49 -0500, Colin Walters wrote:
>   
>  >>I made a huge mess when I started hacking the policy sources
> in
>  >>FC2...  
>  One other note - all my comments were relative to the rawhide
> targeted
>  policy (which in the case of httpd AFAIK isn't very divergent from FC3).
>  However I know the delta between FC2 and FC3 is larger, particularly due
>  to the strict->targeted transition, and it's quite possible there are
>  bugs there (such as the one you are encountering) which are fixed in
>  FC3.  Upgrading very strongly recommended :) 
Yes, I'm happily running the targeted policy in FC3! I was alluding to
my less then elegant attemtps to modify the strict policy in FC2. :)

I fixed the problem with the aspell call by adding the following rules
per Karsten's excellent writeup on making policy changes with a
local.te:

allow httpd_sys_script_t httpd_tmp_t:file read;
allow httpd_sys_script_t httpd_tmp_t:file getattr;

Thanks for your comments and suggestions... much appreciated!

-Tom

[Tom Lisjac]

On Wed, 23 Feb 2005 09:49:06 -0500, Colin Walters <walters(a)redhat.com&gt; wrote:
>  On Tue, 2005-02-22 at 16:44 -0700, Tom Lisjac wrote:
>  
>  >I was under the impression that mod_php and the webserver ran in the
>  >same context...  
>  You are correct; mod_php code does run in the same context as Apache
>  (i.e. httpd_t), because it runs in-process. 
>  >avc:  denied  { getattr } for  pid=32122 exe=/usr/bin/aspell
>  >path=/tmp/spellkQimNQ dev=hda2 ino=326408
>  >scontext=root:system_r:httpd_sys_script_t
>  >tcontext=root:object_r:httpd_tmp_t tclass=file
>  
>  Note however here that the source context is httpd_sys_script_t (not
>  httpd_t), which means it's a CGI script.  CGI scripts by default run in
>  a separate context.
>  
>  Are you really sure that you don't have an external CGI script being
>  run? 
You're right. I looked at the php code and aspell is being called
using an exec... which appears to spawn a shell process. I understand
the distinction now... thanks.

>  Because as best I can tell, the write was done by the main webserver
>  process, and the read is being attempted by a CGI script.
>  
>  Consider the case where Apache keeps temporary data files containing
>  private information in /tmp; in general you don't want CGI scripts to be
>  able to read that. 
That makes sense... especially for things like session information
that could contain login credentials or other personal data.

>  You should probably upgrade to FC3; a huge amount of work has gone
> into
>  the policy (but we still have a lot more to do...). 
I'm running FC3 with SELinux enabled on all my internet facing
servers. :) I never got there wih FC2... it was just too difficult.
Many thanks to everyone who contributed to the FC3 revisions and
targeted policy!

-Tom

[Kodungallur Varma]

Hi all,

       I have my fedora core 3 selinux machine setup. I wrote a policy
to run the following process - spread daemon (Spread tool kit -
www.spread.org).  its running great with the policy. what I want now
is some API's/ system calls that I can use to change the security
context of spread dynamically. in case I am not clear, I am trying to
modify the spread source code so that spread while running, can change
its security contexts dynamically. I downloaded libselinux.XXX rpm,
but I could not get any functions that I can use to access the
functionality. any help in this regard is greatly appreciated. thanx
in advance..

Ram

[Stephen Smalley]

On Tue, 2005-02-22 at 23:26 -0500, Kodungallur Varma wrote:
>         I have my fedora core 3 selinux machine setup. I wrote a
> policy
>  to run the following process - spread daemon (Spread tool kit -
>  www.spread.org).  its running great with the policy. what I want now
>  is some API's/ system calls that I can use to change the security
>  context of spread dynamically. in case I am not clear, I am trying to
>  modify the spread source code so that spread while running, can change
>  its security contexts dynamically. I downloaded libselinux.XXX rpm,
>  but I could not get any functions that I can use to access the
>  functionality. any help in this regard is greatly appreciated. thanx
>  in advance.. 
Historically, SELinux has only support security context transitions via
execve; the application can explicitly request such a transition by
calling setexeccon(3) and then calling execve(), or the policy can
specify an automatic transition using the domain_auto_trans() macro
based on the calling domain and the type assigned to the program
executable.  Exec-based transitions are preferable because one can
control the inheritance of state and the initialization of the process
in the new security context, providing real isolation and protection
between the two security contexts.  More recently, a setcon(3) interface
was added to support dynamic context transitions as you describe for
privilege bracketing by applications that are trusted to maintain
separation between the two contexts, but this should only be used with
great care and only if an exec-based transition is truly infeasible.  As
setcon(3) was a very recent change, I'm not sure that it was even
included in FC3; you may need a more recent kernel and libselinux for
it.

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Colin Walters]

On Tue, 2005-02-22 at 23:26 -0500, Kodungallur Varma wrote:
> Hi all,
>
>        I have my fedora core 3 selinux machine setup. I wrote a policy
> to run the following process - spread daemon (Spread tool kit -
> www.spread.org).  its running great with the policy. what I want now
> is some API's/ system calls that I can use to change the security
> context of spread dynamically. in case I am not clear, I am trying to
> modify the spread source code so that spread while running, can change
> its security contexts dynamically.  
In order to do privilege bracketing?  There is work upstream on "dynamic
transitions" (see the mailing list archives) which can occur outside of
an exec, and it looks to me like the necessary code is in Fedora
rawhide.  However, it is not in FC3.