Two questions: Mailman and staff_u starting a process

[Jeremy Young]

Hello everyone, and thank you in advance for any help or information that
you can offer me.

I'm configuring a server to run Postfix and Mailman for our development
team's test environment.  I've installed and configured Apache and Mailman,
having no problems with either program.  In addition to DISA STIGS, I'm
trying to implement some best practices and make better use of the security
that SELinux can provide.

My first, and more general question, is can a process started by a user
mapped to staff_u could potentially run into any undesirable AVCs?

I've mapped all server administrators to the staff_u SELinux user:

root@DOMAIN-mailman01 in /root >> semanage login -l | grep -i admins
%DOMAIN-LinuxAdmins          staff_u                   s0-s0:c0.c1023

These users are allowed to transition to unconfined_t via sudo:

root@DOMAIN-mailman01 in /home/jyoung_sa >> cat /etc/sudoers.d/linuxadmins
%DOMAIN-LinuxAdmins ALL=(ALL) ROLE=unconfined_r TYPE=unconfined_t ALL

Using "# service $NAME stop|start|restart" as a user in this group, if I
perform an action on, let's say auditd, I notice that the service gets
started with my user context and not as system_u as I would expect.  Am I
correct in thinking that since the staff_u SELinux user has the same roles
(unconfined_r and system_r) as the system_u user, that this is a non-issue,
and the service should perform as normal?

root@DOMAIN-mailman01 in /home/jyoung_sa >> ps auxZ | grep auditd$
staff_u:system_r:auditd_t:s0    root      1830  0.0  0.0  31892   888 ?
   S<sl 10:12   0:00 auditd

My second question is more specific to Mailman and Apache.  I've toggled
many of the unnecessary SELinux booleans to off, and am able to view the
Apache welcome page with the following being true:

root@DOMAIN-mailman01 in /home/jyoung_sa >> rpm -qa | grep selinux
libselinux-2.0.94-5.3.el6_4.1.x86_64
libselinux-python-2.0.94-5.3.el6_4.1.x86_64
libselinux-utils-2.0.94-5.3.el6_4.1.x86_64
selinux-policy-3.7.19-231.el6_5.1.noarch
selinux-policy-targeted-3.7.19-231.el6_5.1.noarch
root@DOMAIN-mailman01 in /home/jyoung_sa >> sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted
root@DOMAIN-mailman01 in /home/jyoung_sa >> semanage boolean -l | grep
"(on"
allow_staff_exec_content       (on   ,   on)  allow_staff_exec_content
unconfined_login               (on   ,   on)  Allow a user to login as an
unconfined domain
allow_postfix_local_write_mail_spool (on   ,   on)  Allow postfix_local
domain full write access to mail_spool directories
init_upstart                   (on   ,   on)  Enable support for upstart as
the init program.
allow_kerberos                 (on   ,   on)  Allow confined applications
to run with kerberos.
allow_domain_fd_use            (on   ,   on)  Allow all domains to use
other domains file descriptors

When attempting to visit the mailman webpage, however, I would get a 500
error from Apache, producing this AVC in the audit log:

root@DOMAIN-mailman01 in /home/jyoung_sa >> ausearch -m avc -ts recent
----
time->Fri Aug  1 10:03:50 2014
node=DOMAIN-mailman01 type=PATH msg=audit(1406905430.337:1109): item=0
name="/usr/lib/mailman/cgi-bin/listinfo" inode=268184 dev=fd:00
mode=0102755 ouid=0 ogid=41 rdev=00:00 obj=system_u:object_r:lib_t:s0
nametype=NORMAL
node=DOMAIN-mailman01 type=CWD msg=audit(1406905430.337:1109):
 cwd="/usr/lib/mailman/cgi-bin"
node=DOMAIN-mailman01 type=SYSCALL msg=audit(1406905430.337:1109):
arch=c000003e syscall=59 success=no exit=-13 a0=7f9d3732c920
a1=7f9d3732dd98 a2=7f9d3732ddb0 a3=7fffbecc4860 items=1 ppid=1595 pid=1777
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48
fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=system_u:system_r:httpd_t:s0 key=(null)
node=DOMAIN-mailman01 type=AVC msg=audit(1406905430.337:1109): avc:  denied
 { execute_no_trans } for  pid=1777 comm="httpd"
path="/usr/lib/mailman/cgi-bin/listinfo" dev=dm-0 ino=268184
scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file


audit2allow generates this module for me:
module mailman 1.0;

require {
type var_log_t;
type lib_t;
type httpd_t;
class file { read execute_no_trans };
}

#============= httpd_t ==============
allow httpd_t lib_t:file execute_no_trans;
allow httpd_t var_log_t:file read;


I tried using "# chcon -t bin_t /usr/lib/mailman/cgi-bin/*" to test, and I
got a different denial message:

----
time->Fri Aug  1 10:27:23 2014
node=ues-mailman01 type=PATH msg=audit(1406906843.430:2887): item=1
name=(null) inode=2097286 dev=fd:02 mode=0100664 ouid=41 ogid=41 rdev=00:00
obj=system_u:object_r:var_log_t:s0 nametype=NORMAL
node=ues-mailman01 type=PATH msg=audit(1406906843.430:2887): item=0
name="/var/log/mailman/" inode=2097282 dev=fd:02 mode=042775 ouid=0 ogid=41
rdev=00:00 obj=system_u:object_r:var_log_t:s0 nametype=PARENT
node=ues-mailman01 type=CWD msg=audit(1406906843.430:2887):
 cwd="/usr/lib/mailman/cgi-bin"
node=ues-mailman01 type=SYSCALL msg=audit(1406906843.430:2887):
arch=c000003e syscall=2 success=no exit=-13 a0=7204f0 a1=442 a2=1b6 a3=0
items=2 ppid=1731 pid=1901 auid=4294967295 uid=48 gid=41 euid=48 suid=48
fsuid=48 egid=41 sgid=41 fsgid=41 tty=(none) ses=4294967295 comm="python"
exe="/usr/bin/python" subj=system_u:system_r:httpd_t:s0 key=(null)
node=ues-mailman01 type=AVC msg=audit(1406906843.430:2887): avc:  denied  {
read } for  pid=1901 comm="python" name="error" dev=dm-2 ino=2097286
scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:var_log_t:s0 tclass=file

Because this is a development environment and is not affecting production,
I'm not terribly concerned with installing the module.  If I'm instructed
to perform the same configuration to our production servers, though, the
SELinux module would require Federal approval.

Can I have someone's opinion about this module?  Is this required, or could
I change the context of the files stored in /usr/lib/mailman/cgi-bin to
something that Apache is allowed to use?  Have I turned off too many
booleans that could have prevented this?

Thank you!

-- 
Jeremy Young <jrm16020(a)gmail.com&gt;, M.S., RHCSA

[Dominick Grift]

On Fri, 2014-08-01 at 10:29 -0500, Jeremy Young wrote:
>  Hello everyone, and thank you in advance for any help or information
>  that you can offer me.  
>  
>  
>  I'm configuring a server to run Postfix and Mailman for our
>  development team's test environment.  I've installed and configured
>  Apache and Mailman, having no problems with either program.  In
>  addition to DISA STIGS, I'm trying to implement some best practices
>  and make better use of the security that SELinux can provide.  
>  
>  
>  My first, and more general question, is can a process started by a
>  user mapped to staff_u could potentially run into any undesirable
>  AVCs?  
>   
Yes it can (i suppose it always can). The question though is not very
clear

however i assume you mean in a stock configuration.

>  I've mapped all server administrators to the staff_u SELinux
> user:
>  
>  
>  root@DOMAIN-mailman01 in /root >> semanage login -l | grep -i admins
>  %DOMAIN-LinuxAdmins          staff_u                   s0-s0:c0.c1023
>  
>  
>  These users are allowed to transition to unconfined_t via sudo:
>  
>  
>  root@DOMAIN-mailman01 in /home/jyoung_sa >>
>  cat /etc/sudoers.d/linuxadmins 
>  %DOMAIN-LinuxAdmins ALL=(ALL) ROLE=unconfined_r TYPE=unconfined_t ALL
>  
>  
>  Using "# service $NAME stop|start|restart" as a user in this group, if
>  I perform an action on, let's say auditd, I notice that the service
>  gets started with my user context and not as system_u as I would
>  expect.  Am I correct in thinking that since the staff_u SELinux user
>  has the same roles (unconfined_r and system_r) as the system_u user,
>  that this is a non-issue, and the service should perform as normal?
>  
>  
>  root@DOMAIN-mailman01 in /home/jyoung_sa >> ps auxZ | grep auditd$
>  staff_u:system_r:auditd_t:s0    root      1830  0.0  0.0  31892
>  888 ?        S<sl 10:12   0:00 auditd
>   
In fedora/rhel is is indeed a non-issue but this is only a non issue
because fedora/rhel made it a non-issue

>  
>  My second question is more specific to Mailman and Apache.  I've
>  toggled many of the unnecessary SELinux booleans to off, and am able
>  to view the Apache welcome page with the following being true:
>  
>  
>  root@DOMAIN-mailman01 in /home/jyoung_sa >> rpm -qa | grep selinux
>  libselinux-2.0.94-5.3.el6_4.1.x86_64
>  libselinux-python-2.0.94-5.3.el6_4.1.x86_64
>  libselinux-utils-2.0.94-5.3.el6_4.1.x86_64
>  selinux-policy-3.7.19-231.el6_5.1.noarch
>  selinux-policy-targeted-3.7.19-231.el6_5.1.noarch
>  root@DOMAIN-mailman01 in /home/jyoung_sa >> sestatus
>  SELinux status:                 enabled
>  SELinuxfs mount:                /selinux
>  Current mode:                   enforcing
>  Mode from config file:          enforcing
>  Policy version:                 24
>  Policy from config file:        targeted
>  root@DOMAIN-mailman01 in /home/jyoung_sa >> semanage boolean -l | grep
>  "(on"
>  allow_staff_exec_content       (on   ,   on)  allow_staff_exec_content
>  unconfined_login               (on   ,   on)  Allow a user to login as
>  an unconfined domain
>  allow_postfix_local_write_mail_spool (on   ,   on)  Allow
>  postfix_local domain full write access to mail_spool directories
>  init_upstart                   (on   ,   on)  Enable support for
>  upstart as the init program.
>  allow_kerberos                 (on   ,   on)  Allow confined
>  applications to run with kerberos.
>  allow_domain_fd_use            (on   ,   on)  Allow all domains to use
>  other domains file descriptors
>  
>  
>  When attempting to visit the mailman webpage, however, I would get a
>  500 error from Apache, producing this AVC in the audit log:
>  
>  
>  root@DOMAIN-mailman01 in /home/jyoung_sa >> ausearch -m avc -ts recent
>  ----
>  time->Fri Aug  1 10:03:50 2014
>  node=DOMAIN-mailman01 type=PATH msg=audit(1406905430.337:1109): item=0
>  name="/usr/lib/mailman/cgi-bin/listinfo" inode=268184 dev=fd:00
>  mode=0102755 ouid=0 ogid=41 rdev=00:00 obj=system_u:object_r:lib_t:s0
>  nametype=NORMAL
>  node=DOMAIN-mailman01 type=CWD msg=audit(1406905430.337:1109):
>   cwd="/usr/lib/mailman/cgi-bin"
>  node=DOMAIN-mailman01 type=SYSCALL msg=audit(1406905430.337:1109):
>  arch=c000003e syscall=59 success=no exit=-13 a0=7f9d3732c920
>  a1=7f9d3732dd98 a2=7f9d3732ddb0 a3=7fffbecc4860 items=1 ppid=1595
>  pid=1777 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48
>  egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd"
>  exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
>  node=DOMAIN-mailman01 type=AVC msg=audit(1406905430.337:1109): avc:
>   denied  { execute_no_trans } for  pid=1777 comm="httpd"
>  path="/usr/lib/mailman/cgi-bin/listinfo" dev=dm-0 ino=268184
>  scontext=system_u:system_r:httpd_t:s0
>  tcontext=system_u:object_r:lib_t:s0 tclass=file
>   
/usr/lib/mailman/cgi-bin/listinfo is mislabeled it is labeled as a
libraries and libraries cannot be executed (libraries are mmapped
instead)

I think you may want to label the file type mailman_cgi_exec_t (should
probably label all executable files in /usr/lib/mailman/cgi-bin/ that
way

>  
>  
>  audit2allow generates this module for me:
>  module mailman 1.0;
>  
>  
>  require {
>  type var_log_t;
>  type lib_t;
>  type httpd_t;
>  class file { read execute_no_trans };
>  }
>  
>  
>  #============= httpd_t ==============
>  allow httpd_t lib_t:file execute_no_trans;
>  allow httpd_t var_log_t:file read;
>  
>  
>  
>  
>  I tried using "# chcon -t bin_t /usr/lib/mailman/cgi-bin/*" to test,
>  and I got a different denial message:
>  
>  
>  ----
>  time->Fri Aug  1 10:27:23 2014
>  node=ues-mailman01 type=PATH msg=audit(1406906843.430:2887): item=1
>  name=(null) inode=2097286 dev=fd:02 mode=0100664 ouid=41 ogid=41
>  rdev=00:00 obj=system_u:object_r:var_log_t:s0 nametype=NORMAL
>  node=ues-mailman01 type=PATH msg=audit(1406906843.430:2887): item=0
>  name="/var/log/mailman/" inode=2097282 dev=fd:02 mode=042775 ouid=0
>  ogid=41 rdev=00:00 obj=system_u:object_r:var_log_t:s0 nametype=PARENT
>  node=ues-mailman01 type=CWD msg=audit(1406906843.430:2887):
>   cwd="/usr/lib/mailman/cgi-bin"
>  node=ues-mailman01 type=SYSCALL msg=audit(1406906843.430:2887):
>  arch=c000003e syscall=2 success=no exit=-13 a0=7204f0 a1=442 a2=1b6
>  a3=0 items=2 ppid=1731 pid=1901 auid=4294967295 uid=48 gid=41 euid=48
>  suid=48 fsuid=48 egid=41 sgid=41 fsgid=41 tty=(none) ses=4294967295
>  comm="python" exe="/usr/bin/python"
> subj=system_u:system_r:httpd_t:s0
>  key=(null)
>  node=ues-mailman01 type=AVC msg=audit(1406906843.430:2887): avc:
>   denied  { read } for  pid=1901 comm="python" name="error" dev=dm-2
>  ino=2097286 scontext=system_u:system_r:httpd_t:s0
>  tcontext=system_u:object_r:var_log_t:s0 tclass=file
>  
>  
>  Because this is a development environment and is not affecting
>  production, I'm not terribly concerned with installing the module.  If
>  I'm instructed to perform the same configuration to our production
>  servers, though, the SELinux module would require Federal approval.  
>  
>  
>  Can I have someone's opinion about this module?  Is this required, or
>  could I change the context of the files stored
>  in /usr/lib/mailman/cgi-bin to something that Apache is allowed to
>  use?  Have I turned off too many booleans that could have prevented
>  this?
>  
>  
>  Thank you!
>  
>  
>  -- 
>  Jeremy Young, M.S., RHCSA
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Jeremy Young]

Hi Dominick,

Thank you for the quick answer!  I noticed that too about the files in
/usr/lib/mailman/cgi-bin being apparently mislabeled, but I don't have that
label available to me.

jyoung_sa@DOMAIN-mailman01 in /home/jyoung_sa >> seinfo -t | grep mailman |
wc -l
0
jyoung_sa@DOMAIN-mailman01 in /home/jyoung_sa >> sudo yum list installed |
grep selinux
This system is not registered to Red Hat Subscription Management. You can
use subscription-manager to register.
libselinux.x86_64              2.0.94-5.3.el6_4.1
@anaconda-RedHatEnterpriseLinux-201311111358.x86_64/6.5
libselinux-python.x86_64       2.0.94-5.3.el6_4.1
@/libselinux-python-2.0.94-5.3.el6_4.1.x86_64
libselinux-utils.x86_64        2.0.94-5.3.el6_4.1
@anaconda-RedHatEnterpriseLinux-201311111358.x86_64/6.5
selinux-policy.noarch          3.7.19-231.el6_5.3   @rhel-6-server-rpms

selinux-policy-targeted.noarch 3.7.19-231.el6_5.3   @rhel-6-server-rpms


For what it's worth, mailman seems to work fine with these labels in place
and using the module that I generated.  That is, at least until the file
context of all of the config.pck files in /var/lib/mailman/lists/ues-all
gets changed when one of the crons installed by mailman changes the context
of those files to cron_var_lib_t.

Thank you again!


On Sat, Aug 2, 2014 at 11:44 AM, Dominick Grift <dominick.grift(a)gmail.com&gt;
wrote:

>  On Fri, 2014-08-01 at 10:29 -0500, Jeremy Young wrote:
>  > Hello everyone, and thank you in advance for any help or information
>  > that you can offer me.
>  >
>  >
>  > I'm configuring a server to run Postfix and Mailman for our
>  > development team's test environment.  I've installed and configured
>  > Apache and Mailman, having no problems with either program.  In
>  > addition to DISA STIGS, I'm trying to implement some best practices
>  > and make better use of the security that SELinux can provide.
>  >
>  >
>  > My first, and more general question, is can a process started by a
>  > user mapped to staff_u could potentially run into any undesirable
>  > AVCs?
>  >
>
>  Yes it can (i suppose it always can). The question though is not very
>  clear
>
>  however i assume you mean in a stock configuration.
>
>  > I've mapped all server administrators to the staff_u SELinux user:
>  >
>  >
>  > root@DOMAIN-mailman01 in /root >> semanage login -l | grep -i admins
>  > %DOMAIN-LinuxAdmins          staff_u                   s0-s0:c0.c1023
>  >
>  >
>  > These users are allowed to transition to unconfined_t via sudo:
>  >
>  >
>  > root@DOMAIN-mailman01 in /home/jyoung_sa >>
>  > cat /etc/sudoers.d/linuxadmins
>  > %DOMAIN-LinuxAdmins ALL=(ALL) ROLE=unconfined_r TYPE=unconfined_t ALL
>  >
>  >
>  > Using "# service $NAME stop|start|restart" as a user in this group, if
>  > I perform an action on, let's say auditd, I notice that the service
>  > gets started with my user context and not as system_u as I would
>  > expect.  Am I correct in thinking that since the staff_u SELinux user
>  > has the same roles (unconfined_r and system_r) as the system_u user,
>  > that this is a non-issue, and the service should perform as normal?
>  >
>  >
>  > root@DOMAIN-mailman01 in /home/jyoung_sa >> ps auxZ | grep auditd$
>  > staff_u:system_r:auditd_t:s0    root      1830  0.0  0.0  31892
>  > 888 ?        S<sl 10:12   0:00 auditd
>  >
>
>  In fedora/rhel is is indeed a non-issue but this is only a non issue
>  because fedora/rhel made it a non-issue
>
>  >
>  > My second question is more specific to Mailman and Apache.  I've
>  > toggled many of the unnecessary SELinux booleans to off, and am able
>  > to view the Apache welcome page with the following being true:
>  >
>  >
>  > root@DOMAIN-mailman01 in /home/jyoung_sa >> rpm -qa | grep selinux
>  > libselinux-2.0.94-5.3.el6_4.1.x86_64
>  > libselinux-python-2.0.94-5.3.el6_4.1.x86_64
>  > libselinux-utils-2.0.94-5.3.el6_4.1.x86_64
>  > selinux-policy-3.7.19-231.el6_5.1.noarch
>  > selinux-policy-targeted-3.7.19-231.el6_5.1.noarch
>  > root@DOMAIN-mailman01 in /home/jyoung_sa >> sestatus
>  > SELinux status:                 enabled
>  > SELinuxfs mount:                /selinux
>  > Current mode:                   enforcing
>  > Mode from config file:          enforcing
>  > Policy version:                 24
>  > Policy from config file:        targeted
>  > root@DOMAIN-mailman01 in /home/jyoung_sa >> semanage boolean -l | grep
>  > "(on"
>  > allow_staff_exec_content       (on   ,   on)  allow_staff_exec_content
>  > unconfined_login               (on   ,   on)  Allow a user to login as
>  > an unconfined domain
>  > allow_postfix_local_write_mail_spool (on   ,   on)  Allow
>  > postfix_local domain full write access to mail_spool directories
>  > init_upstart                   (on   ,   on)  Enable support for
>  > upstart as the init program.
>  > allow_kerberos                 (on   ,   on)  Allow confined
>  > applications to run with kerberos.
>  > allow_domain_fd_use            (on   ,   on)  Allow all domains to use
>  > other domains file descriptors
>  >
>  >
>  > When attempting to visit the mailman webpage, however, I would get a
>  > 500 error from Apache, producing this AVC in the audit log:
>  >
>  >
>  > root@DOMAIN-mailman01 in /home/jyoung_sa >> ausearch -m avc -ts recent
>  > ----
>  > time->Fri Aug  1 10:03:50 2014
>  > node=DOMAIN-mailman01 type=PATH msg=audit(1406905430.337:1109): item=0
>  > name="/usr/lib/mailman/cgi-bin/listinfo" inode=268184 dev=fd:00
>  > mode=0102755 ouid=0 ogid=41 rdev=00:00 obj=system_u:object_r:lib_t:s0
>  > nametype=NORMAL
>  > node=DOMAIN-mailman01 type=CWD msg=audit(1406905430.337:1109):
>  >  cwd="/usr/lib/mailman/cgi-bin"
>  > node=DOMAIN-mailman01 type=SYSCALL msg=audit(1406905430.337:1109):
>  > arch=c000003e syscall=59 success=no exit=-13 a0=7f9d3732c920
>  > a1=7f9d3732dd98 a2=7f9d3732ddb0 a3=7fffbecc4860 items=1 ppid=1595
>  > pid=1777 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48
>  > egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd"
>  > exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
>  > node=DOMAIN-mailman01 type=AVC msg=audit(1406905430.337:1109): avc:
>  >  denied  { execute_no_trans } for  pid=1777 comm="httpd"
>  > path="/usr/lib/mailman/cgi-bin/listinfo" dev=dm-0 ino=268184
>  > scontext=system_u:system_r:httpd_t:s0
>  > tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >
>
>  /usr/lib/mailman/cgi-bin/listinfo is mislabeled it is labeled as a
>  libraries and libraries cannot be executed (libraries are mmapped
>  instead)
>
>  I think you may want to label the file type mailman_cgi_exec_t (should
>  probably label all executable files in /usr/lib/mailman/cgi-bin/ that
>  way
>
>  >
>  >
>  > audit2allow generates this module for me:
>  > module mailman 1.0;
>  >
>  >
>  > require {
>  > type var_log_t;
>  > type lib_t;
>  > type httpd_t;
>  > class file { read execute_no_trans };
>  > }
>  >
>  >
>  > #============= httpd_t ==============
>  > allow httpd_t lib_t:file execute_no_trans;
>  > allow httpd_t var_log_t:file read;
>  >
>  >
>  >
>  >
>  > I tried using "# chcon -t bin_t /usr/lib/mailman/cgi-bin/*" to test,
>  > and I got a different denial message:
>  >
>  >
>  > ----
>  > time->Fri Aug  1 10:27:23 2014
>  > node=ues-mailman01 type=PATH msg=audit(1406906843.430:2887): item=1
>  > name=(null) inode=2097286 dev=fd:02 mode=0100664 ouid=41 ogid=41
>  > rdev=00:00 obj=system_u:object_r:var_log_t:s0 nametype=NORMAL
>  > node=ues-mailman01 type=PATH msg=audit(1406906843.430:2887): item=0
>  > name="/var/log/mailman/" inode=2097282 dev=fd:02 mode=042775 ouid=0
>  > ogid=41 rdev=00:00 obj=system_u:object_r:var_log_t:s0 nametype=PARENT
>  > node=ues-mailman01 type=CWD msg=audit(1406906843.430:2887):
>  >  cwd="/usr/lib/mailman/cgi-bin"
>  > node=ues-mailman01 type=SYSCALL msg=audit(1406906843.430:2887):
>  > arch=c000003e syscall=2 success=no exit=-13 a0=7204f0 a1=442 a2=1b6
>  > a3=0 items=2 ppid=1731 pid=1901 auid=4294967295 uid=48 gid=41 euid=48
>  > suid=48 fsuid=48 egid=41 sgid=41 fsgid=41 tty=(none) ses=4294967295
>  > comm="python" exe="/usr/bin/python"
> subj=system_u:system_r:httpd_t:s0
>  > key=(null)
>  > node=ues-mailman01 type=AVC msg=audit(1406906843.430:2887): avc:
>  >  denied  { read } for  pid=1901 comm="python" name="error"
> dev=dm-2
>  > ino=2097286 scontext=system_u:system_r:httpd_t:s0
>  > tcontext=system_u:object_r:var_log_t:s0 tclass=file
>  >
>  >
>  > Because this is a development environment and is not affecting
>  > production, I'm not terribly concerned with installing the module.  If
>  > I'm instructed to perform the same configuration to our production
>  > servers, though, the SELinux module would require Federal approval.
>  >
>  >
>  > Can I have someone's opinion about this module?  Is this required, or
>  > could I change the context of the files stored
>  > in /usr/lib/mailman/cgi-bin to something that Apache is allowed to
>  > use?  Have I turned off too many booleans that could have prevented
>  > this?
>  >
>  >
>  > Thank you!
>  >
>  >
>  > --
>  > Jeremy Young, M.S., RHCSA
>  > --
>  > selinux mailing list
>  > selinux(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>
>  

-- 
Jeremy Young <jrm16020(a)gmail.com&gt;, M.S., RHCSA

[Dominick Grift]

On Mon, 2014-08-04 at 08:52 -0500, Jeremy Young wrote:
>  Hi Dominick,
>  
>  
>  Thank you for the quick answer!  I noticed that too about the files
>  in /usr/lib/mailman/cgi-bin being apparently mislabeled, but I don't
>  have that label available to me. 
Then you could try httpd_sys_script_exec_t instead or preferably create
your own mailman-cgi-exec type

Your solution sets a non-optimal precedence. You are changing the
meaning of the lib_t type.

[Jeremy Young]

I understand that the files are mislabeled and am hoping for another
solution too.  I can create that type, but am more concerned with this
being the default label assigned to that directory and all of its contents.
 Should this be considered a bug in the latest policy?  An update to my
policy and a filesystem relabel is what's set the context to lib_t in the
first place.

I'll try the label httpd_sys_script_exec_t and report my results.


On Mon, Aug 4, 2014 at 9:43 AM, Dominick Grift <dominick.grift(a)gmail.com&gt;
wrote:

>  On Mon, 2014-08-04 at 08:52 -0500, Jeremy Young wrote:
>  > Hi Dominick,
>  >
>  >
>  > Thank you for the quick answer!  I noticed that too about the files
>  > in /usr/lib/mailman/cgi-bin being apparently mislabeled, but I don't
>  > have that label available to me.
>
>  Then you could try httpd_sys_script_exec_t instead or preferably create
>  your own mailman-cgi-exec type
>
>  Your solution sets a non-optimal precedence. You are changing the
>  meaning of the lib_t type.
>
>
>
>  

-- 
Jeremy Young <jrm16020(a)gmail.com&gt;, M.S., RHCSA

[Dominick Grift]

On Mon, 2014-08-04 at 10:29 -0500, Jeremy Young wrote:
>  I understand that the files are mislabeled and am hoping for another
>  solution too.  I can create that type, but am more concerned with this
>  being the default label assigned to that directory and all of its
>  contents.  Should this be considered a bug in the latest policy?  An
>  update to my policy and a filesystem relabel is what's set the context
>  to lib_t in the first place.
>  
>  
>  I'll try the label httpd_sys_script_exec_t and report my results.
>  
>   
It is a bug in the SELinux security policy. The file (s) is
inappropriately classified as being a library file.

That said, the show must go on, and one can make configuration changes
to fix this "bug". This is what SELinux is all about.

>  On Mon, Aug 4, 2014 at 9:43 AM, Dominick Grift
>  <dominick.grift(a)gmail.com&gt; wrote:
>          On Mon, 2014-08-04 at 08:52 -0500, Jeremy Young wrote:
>          > Hi Dominick,
>          >
>          >
>          > Thank you for the quick answer!  I noticed that too about
>          the files
>          > in /usr/lib/mailman/cgi-bin being apparently mislabeled, but
>          I don't
>          > have that label available to me.
>          
>          Then you could try httpd_sys_script_exec_t instead or
>          preferably create
>          your own mailman-cgi-exec type
>          
>          Your solution sets a non-optimal precedence. You are changing
>          the
>          meaning of the lib_t type.
>          
>          
>          
>  
>  
>  
>  
>  -- 
>  Jeremy Young, M.S., RHCSA
>