syslog-ng creates /dev/log in wrong selinux domain causing avc denials

[Daniel Neuberger]

All,

We are getting AVC denials like the following:

audit.log:type=AVC msg=audit(1363623746.304:77): avc:  denied  { write
} for  pid=7569 comm="audispd" name="log" dev=tmpfs ino=12139
scontext=system_u:system_r:audisp_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=sock_file
audit.log:type=AVC msg=audit(1363628993.829:922): avc:  denied  {
write } for  pid=8402 comm="logger" name="log" dev=tmpfs ino=12139
scontext=user_u:system_r:dhcpc_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=sock_file
audit.log:type=AVC msg=audit(1363628997.219:952): avc:  denied  {
write } for  pid=8808 comm="dhclient" name="log" dev=tmpfs ino=12139
scontext=user_u:system_r:dhcpc_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=sock_file
audit.log:type=AVC msg=audit(1363628997.285:955): avc:  denied  {
write } for  pid=8808 comm="dhclient" name="log" dev=tmpfs ino=12139
scontext=user_u:system_r:dhcpc_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=sock_file
...
audit.log:type=AVC msg=audit(1363629158.017:1081): avc:  denied  {
write } for  pid=9213 comm="logger" name="log" dev=tmpfs ino=12139
scontext=user_u:system_r:dhcpc_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=sock_file
audit.log:type=AVC msg=audit(1363629420.696:1144): avc:  denied  {
write } for  pid=4944 comm="ntpd" name="log" dev=tmpfs ino=12139
scontext=system_u:system_r:ntpd_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=sock_file
audit.log:type=AVC msg=audit(1363629420.807:1145): avc:  denied  {
write } for  pid=9700 comm="ntpd" name="log" dev=tmpfs ino=12139
scontext=user_u:system_r:ntpd_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=sock_file
audit.log:type=AVC msg=audit(1363634382.869:2143): avc:  denied  {
write } for  pid=9973 comm="groupadd" name="log" dev=tmpfs ino=32837
scontext=user_u:system_r:groupadd_t:s0
tcontext=user_u:object_r:device_t:s0 tclass=sock_file
...

The problem seems to be that syslog-ng is creating /dev/log in the wrong domain:

[root@foo ~]$ ls -Z /dev/log
srw-rw-rw-  root root user_u:object_r:device_t:s0      /dev/log
[root@foo ~]$ chcon system_u:object_r:devlog_t:s0 /dev/log
[root@foo ~]$ ls -Z /dev/log
srw-rw-rw-  root root system_u:object_r:devlog_t:s0    /dev/log
[root@foo ~]$ run_init /etc/init.d/syslog-ng restart
Authenticating foobar.
Password:
Restarting syslog-ng: Stopping syslog-ng:                  [  OK  ]
Starting syslog-ng:                                        [  OK  ]
[root@foo ~]$ ls -Z /dev/log
srw-rw-rw-  root root user_u:object_r:device_t:s0      /dev/log

I think this is because the syslog-ng daemon is running in the wrong
domain.  It never transitions from the initrc_t domain:

[root@foo log]$ ps -efZ | grep syslog
system_u:system_r:initrc_t:s0   root      4912     1  0 16:20 ?
00:00:00 supervising syslog-ng
system_u:system_r:initrc_t:s0   root      4913  4912  0 16:20 ?
00:00:00 /opt/syslog-ng/sbin/syslog-ng --no-caps

The problem - I think - is that we're using a syslog-ng rpm from the
vendor's website that installs to /opt rather than /usr as the
targeted policy seems to expect meaning the daemon and everything has
the wrong file contexts.  I tried fixing this by updating the contexts
based off the settings in the logging.fc file from the policy src.rpm,
but that didn't help:

[root@foo ~]$ chcon system_u:object_r:syslog_conf_t:s0 /opt/syslog-ng/etc/*
[root@foo ~]$ chcon system_u:object_r:syslogd_exec_t:s0 /opt/syslog-ng/sbin/*
[root@foo ~]$ chcon system_u:object_r:syslogd_var_lib_t:s0
/opt/syslog-ng/var/syslog-ng.persist
[root@foo ~]$ chcon system_u:object_r:syslogd_var_lib_t:s0
/opt/syslog-ng/var/run/*
[root@foo ~]$ run_init /etc/init.d/syslog-ng restart
Authenticating foobar.
Password:
Restarting syslog-ng: Stopping syslog-ng:                  [  OK  ]
Starting syslog-ng:                                        [  OK  ]
[root@foo ~]$ ls -Z /dev/log
srw-rw-rw-  root root user_u:object_r:device_t:s0      /dev/log
[root@foo ~]$ ps -efZ | grep syslog
user_u:system_r:initrc_t:s0     root      6594     1  0 14:35 ?
00:00:00 supervising syslog-ng
user_u:system_r:initrc_t:s0     root      6595  6594  0 14:35 ?
00:00:00 /opt/syslog-ng/sbin/syslog-ng --no-caps

Restarting after making these changes, didn't help either.  At this
point, I'm out of ideas for how to properly fix the problem.  I also
tried relabeling the whole system, then applying the above changes and
that didn't help.

FYI, we are running a RHEL 5.5 system, but are using the RHEL 5.7
kernel and selinux rpms including:

libselinux-1.33.4-5.7.el5.i386
libselinux-1.33.4-5.7.el5.x86_64
libselinux-python-1.33.4-5.7.el5.x86_64
libselinux-utils-1.33.4-5.7.el5.x86_64
selinux-policy-2.4.6-316.el5.noarch
selinux-policy-targeted-2.4.6-316.el5.noarch

We're using syslog-ng-3.1.4-1.rhel5.x86_64.rpm from the vendor's
website which installs everything in /opt/syslog-ng rather than the
normal RHEL locations.

Any pointers would be much appreciated.  I'm assuming I should be able
to fix this without modifying the policy, but maybe I'm missing
something.

Thanks.

- Daniel

[Dominick Grift]

On Tue, 2013-03-19 at 11:05 -0400, Daniel Neuberger wrote:

>  I think this is because the syslog-ng daemon is running in the wrong
>  domain.  It never transitions from the initrc_t domain:
>  
>  [root@foo log]$ ps -efZ | grep syslog
>  system_u:system_r:initrc_t:s0   root      4912     1  0 16:20 ?
>  00:00:00 supervising syslog-ng
>  system_u:system_r:initrc_t:s0   root      4913  4912  0 16:20 ?
>  00:00:00 /opt/syslog-ng/sbin/syslog-ng --no-caps
>  
>  The problem - I think - is that we're using a syslog-ng rpm from the
>  vendor's website that installs to /opt rather than /usr as the
>  targeted policy seems to expect meaning the daemon and everything has
>  the wrong file contexts.  I tried fixing this by updating the contexts
>  based off the settings in the logging.fc file from the policy src.rpm,
>  but that didn't help:
>  
>  [root@foo ~]$ chcon system_u:object_r:syslog_conf_t:s0 /opt/syslog-ng/etc/*
>  [root@foo ~]$ chcon system_u:object_r:syslogd_exec_t:s0 /opt/syslog-ng/sbin/*
>  [root@foo ~]$ chcon system_u:object_r:syslogd_var_lib_t:s0
>  /opt/syslog-ng/var/syslog-ng.persist
>  [root@foo ~]$ chcon system_u:object_r:syslogd_var_lib_t:s0
>  /opt/syslog-ng/var/run/*
>  [root@foo ~]$ run_init /etc/init.d/syslog-ng restart
>  Authenticating foobar.
>  Password:
>  Restarting syslog-ng: Stopping syslog-ng:                  [  OK  ]
>  Starting syslog-ng:                                        [  OK  ]
>  [root@foo ~]$ ls -Z /dev/log
>  srw-rw-rw-  root root user_u:object_r:device_t:s0      /dev/log
>  [root@foo ~]$ ps -efZ | grep syslog
>  user_u:system_r:initrc_t:s0     root      6594     1  0 14:35 ?
>  00:00:00 supervising syslog-ng
>  user_u:system_r:initrc_t:s0     root      6595  6594  0 14:35 ?
>  00:00:00 /opt/syslog-ng/sbin/syslog-ng --no-caps 
Domain type transitions happen on execve. So you need to make sure that
both the init script as well as the syslog executable file are labeled
properly.

its like this:

init_t -> initrc_exec_t -> initrc_t -> syslog_exec_t -> syslogd_t

You seem to be hanging at initrc_t so i suspect that your syslog
executable file is mislabeled.

Verify the syslogd init script file and see what it runs when it starts
syslog, then see if that file has a proper label.

>  Thanks.
>  
>  - Daniel
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Daniel Neuberger]

On Tue, Mar 19, 2013 at 11:50 AM, Dominick Grift
<dominick.grift(a)gmail.com&gt; wrote:
>  Domain type transitions happen on execve. So you need to make sure
> that
>  both the init script as well as the syslog executable file are labeled
>  properly.
>
>  its like this:
>
>  init_t -> initrc_exec_t -> initrc_t -> syslog_exec_t -> syslogd_t
>
>  You seem to be hanging at initrc_t so i suspect that your syslog
>  executable file is mislabeled.
>
>  Verify the syslogd init script file and see what it runs when it starts
>  syslog, then see if that file has a proper label. 
Thanks Dominick.  The file run by the syslogd init script has the
proper label, but I realized that the init script itself was labeled
initrc_t instead of sylogd_script_exec_t, but fixing that still didn't
help:

[root@foo ~]$ chcon system_u:object_r:syslogd_script_exec_t:s0
/etc/init.d/syslog-ng
[root@foo ~]$ ls -Z /etc/init.d/syslog-ng /opt/syslog-ng/sbin/syslog-ng
-rwxr-xr-x  root root system_u:object_r:syslogd_script_exec_t:s0
/etc/init.d/syslog-ng
-rwxr-xr-x  root root system_u:object_r:syslogd_exec_t:s0
/opt/syslog-ng/sbin/syslog-ng
[root@foo ~]$ run_init /etc/init.d/syslog-ng restart
Authenticating foobar.
Password:
Restarting syslog-ng: Stopping syslog-ng:                  [  OK  ]
Starting syslog-ng:                                        [  OK  ]
[root@foo ~]$ ps -efZ | grep syslog
user_u:system_r:initrc_t:s0     root      7199     1  0 16:30 ?
00:00:00 supervising syslog-ng
user_u:system_r:initrc_t:s0     root      7200  7199  0 16:30 ?
00:00:00 /opt/syslog-ng/sbin/syslog-ng --no-caps

I agree with your diagnosis, but fixing the labeling doesn't seem to
help.  Any other ideas?

Thanks.

- Daniel

[Dominick Grift]

On Tue, 2013-03-19 at 12:40 -0400, Daniel Neuberger wrote:
>  On Tue, Mar 19, 2013 at 11:50 AM, Dominick Grift
>  <dominick.grift(a)gmail.com&gt; wrote:
>  > Domain type transitions happen on execve. So you need to make sure that
>  > both the init script as well as the syslog executable file are labeled
>  > properly.
>  >
>  > its like this:
>  >
>  > init_t -> initrc_exec_t -> initrc_t -> syslog_exec_t -> syslogd_t
>  >
>  > You seem to be hanging at initrc_t so i suspect that your syslog
>  > executable file is mislabeled.
>  >
>  > Verify the syslogd init script file and see what it runs when it starts
>  > syslog, then see if that file has a proper label.
>  
>  Thanks Dominick.  The file run by the syslogd init script has the
>  proper label, but I realized that the init script itself was labeled
>  initrc_t instead of sylogd_script_exec_t, but fixing that still didn't
>  help:
>  
>  [root@foo ~]$ chcon system_u:object_r:syslogd_script_exec_t:s0
>  /etc/init.d/syslog-ng
>  [root@foo ~]$ ls -Z /etc/init.d/syslog-ng /opt/syslog-ng/sbin/syslog-ng
>  -rwxr-xr-x  root root system_u:object_r:syslogd_script_exec_t:s0
>  /etc/init.d/syslog-ng
>  -rwxr-xr-x  root root system_u:object_r:syslogd_exec_t:s0
>  /opt/syslog-ng/sbin/syslog-ng
>  [root@foo ~]$ run_init /etc/init.d/syslog-ng restart
>  Authenticating foobar.
>  Password:
>  Restarting syslog-ng: Stopping syslog-ng:                  [  OK  ]
>  Starting syslog-ng:                                        [  OK  ]
>  [root@foo ~]$ ps -efZ | grep syslog
>  user_u:system_r:initrc_t:s0     root      7199     1  0 16:30 ?
>  00:00:00 supervising syslog-ng
>  user_u:system_r:initrc_t:s0     root      7200  7199  0 16:30 ?
>  00:00:00 /opt/syslog-ng/sbin/syslog-ng --no-caps
>  
>  I agree with your diagnosis, but fixing the labeling doesn't seem to
>  help.  Any other ideas?
>   
Stephen has a good suggestion. See if your /opt is mounted with nosuid.
If it is then it cannot domain type transition.

>  Thanks.
>  
>  - Daniel

[Stephen Smalley]

On 03/19/2013 11:05 AM, Daniel Neuberger wrote:
>  All,
>
>  We are getting AVC denials like the following:
>
>  audit.log:type=AVC msg=audit(1363623746.304:77): avc:  denied  { write
>  } for  pid=7569 comm="audispd" name="log" dev=tmpfs ino=12139
>  scontext=system_u:system_r:audisp_t:s0
>  tcontext=system_u:object_r:device_t:s0 tclass=sock_file
>  audit.log:type=AVC msg=audit(1363628993.829:922): avc:  denied  {
>  write } for  pid=8402 comm="logger" name="log" dev=tmpfs ino=12139
>  scontext=user_u:system_r:dhcpc_t:s0
>  tcontext=system_u:object_r:device_t:s0 tclass=sock_file
>  audit.log:type=AVC msg=audit(1363628997.219:952): avc:  denied  {
>  write } for  pid=8808 comm="dhclient" name="log" dev=tmpfs ino=12139
>  scontext=user_u:system_r:dhcpc_t:s0
>  tcontext=system_u:object_r:device_t:s0 tclass=sock_file
>  audit.log:type=AVC msg=audit(1363628997.285:955): avc:  denied  {
>  write } for  pid=8808 comm="dhclient" name="log" dev=tmpfs ino=12139
>  scontext=user_u:system_r:dhcpc_t:s0
>  tcontext=system_u:object_r:device_t:s0 tclass=sock_file
>  ...
>  audit.log:type=AVC msg=audit(1363629158.017:1081): avc:  denied  {
>  write } for  pid=9213 comm="logger" name="log" dev=tmpfs ino=12139
>  scontext=user_u:system_r:dhcpc_t:s0
>  tcontext=system_u:object_r:device_t:s0 tclass=sock_file
>  audit.log:type=AVC msg=audit(1363629420.696:1144): avc:  denied  {
>  write } for  pid=4944 comm="ntpd" name="log" dev=tmpfs ino=12139
>  scontext=system_u:system_r:ntpd_t:s0
>  tcontext=system_u:object_r:device_t:s0 tclass=sock_file
>  audit.log:type=AVC msg=audit(1363629420.807:1145): avc:  denied  {
>  write } for  pid=9700 comm="ntpd" name="log" dev=tmpfs ino=12139
>  scontext=user_u:system_r:ntpd_t:s0
>  tcontext=system_u:object_r:device_t:s0 tclass=sock_file
>  audit.log:type=AVC msg=audit(1363634382.869:2143): avc:  denied  {
>  write } for  pid=9973 comm="groupadd" name="log" dev=tmpfs ino=32837
>  scontext=user_u:system_r:groupadd_t:s0
>  tcontext=user_u:object_r:device_t:s0 tclass=sock_file
>  ...
>
>  The problem seems to be that syslog-ng is creating /dev/log in the wrong domain:
>
>  [root@foo ~]$ ls -Z /dev/log
>  srw-rw-rw-  root root user_u:object_r:device_t:s0      /dev/log
>  [root@foo ~]$ chcon system_u:object_r:devlog_t:s0 /dev/log
>  [root@foo ~]$ ls -Z /dev/log
>  srw-rw-rw-  root root system_u:object_r:devlog_t:s0    /dev/log
>  [root@foo ~]$ run_init /etc/init.d/syslog-ng restart
>  Authenticating foobar.
>  Password:
>  Restarting syslog-ng: Stopping syslog-ng:                  [  OK  ]
>  Starting syslog-ng:                                        [  OK  ]
>  [root@foo ~]$ ls -Z /dev/log
>  srw-rw-rw-  root root user_u:object_r:device_t:s0      /dev/log
>
>  I think this is because the syslog-ng daemon is running in the wrong
>  domain.  It never transitions from the initrc_t domain:
>
>  [root@foo log]$ ps -efZ | grep syslog
>  system_u:system_r:initrc_t:s0   root      4912     1  0 16:20 ?
>  00:00:00 supervising syslog-ng
>  system_u:system_r:initrc_t:s0   root      4913  4912  0 16:20 ?
>  00:00:00 /opt/syslog-ng/sbin/syslog-ng --no-caps
>
>  The problem - I think - is that we're using a syslog-ng rpm from the
>  vendor's website that installs to /opt rather than /usr as the
>  targeted policy seems to expect meaning the daemon and everything has
>  the wrong file contexts.  I tried fixing this by updating the contexts
>  based off the settings in the logging.fc file from the policy src.rpm,
>  but that didn't help:
>
>  [root@foo ~]$ chcon system_u:object_r:syslog_conf_t:s0 /opt/syslog-ng/etc/*
>  [root@foo ~]$ chcon system_u:object_r:syslogd_exec_t:s0 /opt/syslog-ng/sbin/*
>  [root@foo ~]$ chcon system_u:object_r:syslogd_var_lib_t:s0
>  /opt/syslog-ng/var/syslog-ng.persist
>  [root@foo ~]$ chcon system_u:object_r:syslogd_var_lib_t:s0
>  /opt/syslog-ng/var/run/*
>  [root@foo ~]$ run_init /etc/init.d/syslog-ng restart
>  Authenticating foobar.
>  Password:
>  Restarting syslog-ng: Stopping syslog-ng:                  [  OK  ]
>  Starting syslog-ng:                                        [  OK  ]
>  [root@foo ~]$ ls -Z /dev/log
>  srw-rw-rw-  root root user_u:object_r:device_t:s0      /dev/log
>  [root@foo ~]$ ps -efZ | grep syslog
>  user_u:system_r:initrc_t:s0     root      6594     1  0 14:35 ?
>  00:00:00 supervising syslog-ng
>  user_u:system_r:initrc_t:s0     root      6595  6594  0 14:35 ?
>  00:00:00 /opt/syslog-ng/sbin/syslog-ng --no-caps
>
>  Restarting after making these changes, didn't help either.  At this
>  point, I'm out of ideas for how to properly fix the problem.  I also
>  tried relabeling the whole system, then applying the above changes and
>  that didn't help.
>
>  FYI, we are running a RHEL 5.5 system, but are using the RHEL 5.7
>  kernel and selinux rpms including:
>
>  libselinux-1.33.4-5.7.el5.i386
>  libselinux-1.33.4-5.7.el5.x86_64
>  libselinux-python-1.33.4-5.7.el5.x86_64
>  libselinux-utils-1.33.4-5.7.el5.x86_64
>  selinux-policy-2.4.6-316.el5.noarch
>  selinux-policy-targeted-2.4.6-316.el5.noarch
>
>  We're using syslog-ng-3.1.4-1.rhel5.x86_64.rpm from the vendor's
>  website which installs everything in /opt/syslog-ng rather than the
>  normal RHEL locations.
>
>  Any pointers would be much appreciated.  I'm assuming I should be able
>  to fix this without modifying the policy, but maybe I'm missing
>  something. 
Is /opt mounted with nosuid flags?  If so, that will suppress the domain 
transition even if the executable is labeled correctly.

Did you confirm that /opt/syslog-ng/sbin/syslog-ng has the right 
security context with an ls -Z after running the chcon command?  Also, 
if you want this to persist across relabels, you will need to use 
semanage fcontext -a to add definitions to the file_contexts 
configuration for these files so that subsequent relabels will not reset 
them each time.

[Daniel Neuberger]

On 03/19/2013 12:41 PM, Stephen Smalley wrote:
>  Is /opt mounted with nosuid flags?  If so, that will suppress the
> domain
>  transition even if the executable is labeled correctly. 
That's it!!!  Well mostly...  Removing nosuid from /opt and rebooting 
worked except that syslog-ng isn't starting at all now due to the 
following denials:
-------------
type=AVC msg=audit(1363713616.722:556): avc:  denied  { execute_no_trans 
} for  pid=5857 comm="syslog-ng"
path="/opt/syslog-ng/libexec/syslog-ng" 
dev=dm-6 ino=190556 scontext=user_u:system_r:syslogd_t:s0 
tcontext=system_u:object_r:syslogd_exec_t:s0 tclass=file

type=SYSCALL msg=audit(1363713616.722:556): arch=c000003e syscall=59 
success=no exit=-13 a0=400740 a1=7fffe72f8908 a2=1a2e5010 a3=0 items=1 
ppid=5849 pid=5857 auid=515 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
sgid=0 fsgid=0 tty=pts1 ses=2 comm="syslog-ng" 
exe="/opt/syslog-ng/sbin/syslog-ng" subj=user_u:system_r:syslogd_t:s0 
key=(null)

type=CWD msg=audit(1363713616.722:556): cwd="/"

type=PATH msg=audit(1363713616.722:556): item=0 
name="/opt/syslog-ng/libexec/syslog-ng" inode=190556 dev=fd:06 
mode=0100755 ouid=0 ogid=0 rdev=00:00 
obj=system_u:object_r:syslogd_exec_t:s0
-------------
In plain English from sealert, 'SELinux is preventing syslog-ng 
(syslogd_t) "execute_no_trans" to /opt/syslog-ng/libexec/syslog-ng 
(syslogd_exec_t).'

Is system_u:object_r:syslogd_exec_t:s0 the wrong label for 
/opt/syslog-ng/libexec/syslog-ng?  I tried this instead to no avail:

[root@sdi-u-unstable audit]$ chcon system_u:object_r:syslogd_t:s0 
/opt/syslog-ng/libexec/syslog-ng
chcon: failed to change context of /opt/syslog-ng/libexec/syslog-ng to 
system_u:object_r:syslogd_t:s0: Permission denied

At this point, I'm unsure if it's a labeling problem or if I need to add 
a new rule due to the addition of /opt/syslog-ng/libexec/syslog-ng in 
the newer versions of syslog-ng.

Thanks for all the help.

- Daniel

[Stephen Smalley]

On 03/19/2013 01:42 PM, Daniel Neuberger wrote:
>  On 03/19/2013 12:41 PM, Stephen Smalley wrote:
> > Is /opt mounted with nosuid flags?  If so, that will suppress the domain
> > transition even if the executable is labeled correctly.
>
>  That's it!!!  Well mostly...  Removing nosuid from /opt and rebooting
>  worked except that syslog-ng isn't starting at all now due to the
>  following denials:
>  -------------
>  type=AVC msg=audit(1363713616.722:556): avc:  denied  { execute_no_trans
>  } for  pid=5857 comm="syslog-ng"
> path="/opt/syslog-ng/libexec/syslog-ng"
>  dev=dm-6 ino=190556 scontext=user_u:system_r:syslogd_t:s0
>  tcontext=system_u:object_r:syslogd_exec_t:s0 tclass=file
>
>  type=SYSCALL msg=audit(1363713616.722:556): arch=c000003e syscall=59
>  success=no exit=-13 a0=400740 a1=7fffe72f8908 a2=1a2e5010 a3=0 items=1
>  ppid=5849 pid=5857 auid=515 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
>  sgid=0 fsgid=0 tty=pts1 ses=2 comm="syslog-ng"
>  exe="/opt/syslog-ng/sbin/syslog-ng" subj=user_u:system_r:syslogd_t:s0
>  key=(null)
>
>  type=CWD msg=audit(1363713616.722:556): cwd="/"
>
>  type=PATH msg=audit(1363713616.722:556): item=0
>  name="/opt/syslog-ng/libexec/syslog-ng" inode=190556 dev=fd:06
>  mode=0100755 ouid=0 ogid=0 rdev=00:00
>  obj=system_u:object_r:syslogd_exec_t:s0
>  -------------
>  In plain English from sealert, 'SELinux is preventing syslog-ng
>  (syslogd_t) "execute_no_trans" to /opt/syslog-ng/libexec/syslog-ng
>  (syslogd_exec_t).'
>
>  Is system_u:object_r:syslogd_exec_t:s0 the wrong label for
>  /opt/syslog-ng/libexec/syslog-ng?  I tried this instead to no avail:
>
>  [root@sdi-u-unstable audit]$ chcon system_u:object_r:syslogd_t:s0
>  /opt/syslog-ng/libexec/syslog-ng
>  chcon: failed to change context of /opt/syslog-ng/libexec/syslog-ng to
>  system_u:object_r:syslogd_t:s0: Permission denied
>
>  At this point, I'm unsure if it's a labeling problem or if I need to add
>  a new rule due to the addition of /opt/syslog-ng/libexec/syslog-ng in
>  the newer versions of syslog-ng. 
Normally you would only label the entrypoint executable for syslogd 
(i.e. the executable invoked to launch syslogd) with syslogd_exec_t, not 
helper programs internally called by it.  Anything else would get 
labeled with a different type, which could just be bin_t for libexec 
files.  But you may also need to add an allow rule via local policy 
module to allow this if it is new behavior for syslog-ng.

[Stephen Smalley]

On 03/19/2013 01:57 PM, Stephen Smalley wrote:
>  On 03/19/2013 01:42 PM, Daniel Neuberger wrote:
> > On 03/19/2013 12:41 PM, Stephen Smalley wrote:
> >> Is /opt mounted with nosuid flags?  If so, that will suppress the domain
> >> transition even if the executable is labeled correctly.
> >
> > That's it!!!  Well mostly...  Removing nosuid from /opt and rebooting
> > worked except that syslog-ng isn't starting at all now due to the
> > following denials:
> > -------------
> > type=AVC msg=audit(1363713616.722:556): avc:  denied  { execute_no_trans
> > } for  pid=5857 comm="syslog-ng"
> path="/opt/syslog-ng/libexec/syslog-ng"
> > dev=dm-6 ino=190556 scontext=user_u:system_r:syslogd_t:s0
> > tcontext=system_u:object_r:syslogd_exec_t:s0 tclass=file
> >
> > type=SYSCALL msg=audit(1363713616.722:556): arch=c000003e syscall=59
> > success=no exit=-13 a0=400740 a1=7fffe72f8908 a2=1a2e5010 a3=0 items=1
> > ppid=5849 pid=5857 auid=515 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> > sgid=0 fsgid=0 tty=pts1 ses=2 comm="syslog-ng"
> > exe="/opt/syslog-ng/sbin/syslog-ng" subj=user_u:system_r:syslogd_t:s0
> > key=(null)
> >
> > type=CWD msg=audit(1363713616.722:556): cwd="/"
> >
> > type=PATH msg=audit(1363713616.722:556): item=0
> > name="/opt/syslog-ng/libexec/syslog-ng" inode=190556 dev=fd:06
> > mode=0100755 ouid=0 ogid=0 rdev=00:00
> > obj=system_u:object_r:syslogd_exec_t:s0
> > -------------
> > In plain English from sealert, 'SELinux is preventing syslog-ng
> > (syslogd_t) "execute_no_trans" to /opt/syslog-ng/libexec/syslog-ng
> > (syslogd_exec_t).'
> >
> > Is system_u:object_r:syslogd_exec_t:s0 the wrong label for
> > /opt/syslog-ng/libexec/syslog-ng?  I tried this instead to no avail:
> >
> > [root@sdi-u-unstable audit]$ chcon system_u:object_r:syslogd_t:s0
> > /opt/syslog-ng/libexec/syslog-ng
> > chcon: failed to change context of /opt/syslog-ng/libexec/syslog-ng to
> > system_u:object_r:syslogd_t:s0: Permission denied
> >
> > At this point, I'm unsure if it's a labeling problem or if I need to add
> > a new rule due to the addition of /opt/syslog-ng/libexec/syslog-ng in
> > the newer versions of syslog-ng.
>
>  Normally you would only label the entrypoint executable for syslogd
>  (i.e. the executable invoked to launch syslogd) with syslogd_exec_t, not
>  helper programs internally called by it.  Anything else would get
>  labeled with a different type, which could just be bin_t for libexec
>  files.  But you may also need to add an allow rule via local policy
>  module to allow this if it is new behavior for syslog-ng. 
Also, what you tried to do (in labeling the libexec file with syslogd_t) 
isn't desirable because it conflates a domain type (syslogd_t) used for 
processes with a file type (e.g. syslogd_exec_t, bin_t, ...).  The only 
case where a domain type should appear on a "file" is for the /proc/pid 
entries associated with a process in that domain.  It shouldn't be used 
on regular files.

[Daniel Neuberger]

On 03/19/2013 02:00 PM, Stephen Smalley wrote:
> > Normally you would only label the entrypoint executable for
> syslogd
> > (i.e. the executable invoked to launch syslogd) with syslogd_exec_t, not
> > helper programs internally called by it.  Anything else would get
> > labeled with a different type, which could just be bin_t for libexec
> > files.  But you may also need to add an allow rule via local policy
> > module to allow this if it is new behavior for syslog-ng.
>
>  Also, what you tried to do (in labeling the libexec file with syslogd_t)
>  isn't desirable because it conflates a domain type (syslogd_t) used for
>  processes with a file type (e.g. syslogd_exec_t, bin_t, ...).  The only
>  case where a domain type should appear on a "file" is for the /proc/pid
>  entries associated with a process in that domain.  It shouldn't be used
>  on regular files. 
Thanks!  Using your advice, I was able to get it working by adding the 
below to the policy:
----------------------------
require {
         type syslogd_t;
         type var_t;
         type bin_t;
         class process getsched;
         class file { read execute execute_no_trans };
         class dir write;
}

#============= syslogd_t ==============
allow syslogd_t bin_t:file { read execute execute_no_trans };
allow syslogd_t self:process getsched;
allow syslogd_t var_t:dir write;
----------------------------
Any recommendations on whether that seems like the right solution?  I'm 
new to writing policy, but it seems too permissive to me.  Anyone have a 
reference that would help me to recognize the difference between a good 
policy and something that just allows whatever to make it work?

Also, why does nosuid suppress domain transitions?  I couldn't find any 
details on Google or in the RHEL docs.

Thanks again for all the help.

[Stephen Smalley]

On 03/19/2013 03:39 PM, Daniel Neuberger wrote:
>  On 03/19/2013 02:00 PM, Stephen Smalley wrote:
> >> Normally you would only label the entrypoint executable for syslogd
> >> (i.e. the executable invoked to launch syslogd) with syslogd_exec_t, not
> >> helper programs internally called by it.  Anything else would get
> >> labeled with a different type, which could just be bin_t for libexec
> >> files.  But you may also need to add an allow rule via local policy
> >> module to allow this if it is new behavior for syslog-ng.
> >
> > Also, what you tried to do (in labeling the libexec file with syslogd_t)
> > isn't desirable because it conflates a domain type (syslogd_t) used for
> > processes with a file type (e.g. syslogd_exec_t, bin_t, ...).  The only
> > case where a domain type should appear on a "file" is for the /proc/pid
> > entries associated with a process in that domain.  It shouldn't be used
> > on regular files.
>
>  Thanks!  Using your advice, I was able to get it working by adding the
>  below to the policy:
>  ----------------------------
>  require {
>           type syslogd_t;
>           type var_t;
>           type bin_t;
>           class process getsched;
>           class file { read execute execute_no_trans };
>           class dir write;
>  }
>
>  #============= syslogd_t ==============
>  allow syslogd_t bin_t:file { read execute execute_no_trans };
>  allow syslogd_t self:process getsched;
>  allow syslogd_t var_t:dir write;
>  ----------------------------
>  Any recommendations on whether that seems like the right solution?  I'm
>  new to writing policy, but it seems too permissive to me.  Anyone have a
>  reference that would help me to recognize the difference between a good
>  policy and something that just allows whatever to make it work?
>
>  Also, why does nosuid suppress domain transitions?  I couldn't find any
>  details on Google or in the RHEL docs.
>
>  Thanks again for all the help. 
Not sure why you need the getsched rule; that should already be allowed.

The var_t rule seems too broad; I suspect you should have a more 
specific type on the directory in question (would have to see the audit 
messages).

We followed the existing convention that nosuid disables security state 
changes for executables in that filesystem and applied it to SELinux 
security contexts in addition to the existing restrictions on 
setuid/setgid executables.  If you didn't trust setuid/setgid bits from 
that filesystem, why would you trust security contexts from it?  But in 
retrospect, it might have been better to have a separate flag for that 
purpose.

[Daniel Neuberger]

On 03/19/2013 04:01 PM, Stephen Smalley wrote:
>  We followed the existing convention that nosuid disables security
> state
>  changes for executables in that filesystem and applied it to SELinux
>  security contexts in addition to the existing restrictions on
>  setuid/setgid executables.  If you didn't trust setuid/setgid bits from
>  that filesystem, why would you trust security contexts from it?  But in
>  retrospect, it might have been better to have a separate flag for that
>  purpose. 
Interesting.  I guess I can see both sides.  In our case, we have a 
separate requirement to specify nosuid, but now we have to justify not 
doing so in order to keep SELinux working.  So it makes sense to me from 
a technical standpoint, but decisions aren't always made that way.  So I 
agree that having a separate flag would be useful to allow more 
flexibility.  Thanks for the explanation.

One more question.  I tried putting my semanage calls to update the file 
contexts in a custom rpm depending on the selinux-policy-targeted rpm. 
In the rpm scriptlet, I first made all the semanage calls and then 
called restorecon on the appropriate paths so that the new file contexts 
would be applied without having to relabel the entire file system.  This 
all works except when the rpm is installed by anaconda during a 
kickstart install.  In that case, I have to run restorecon again during 
kspost or manually after the install.  Any ideas why or suggestions for 
a better solution?

For those interested, here is a summary of the complete solution to get 
the syslog-ng daemon as installed by the balabit rpms on RHEL 5 working 
with selinux:

* Make sure nosuid is not set on /opt
* Update file contexts:
/usr/sbin/semanage fcontext -a -t syslogd_script_exec_t 
/etc/init.d/syslog-ng
/usr/sbin/semanage fcontext -a -t syslogd_exec_t 
/opt/syslog-ng/sbin/syslog-ng
/usr/sbin/semanage fcontext -a -t var_run_t /opt/syslog-ng/var/run
/usr/sbin/semanage fcontext -a -t syslogd_var_lib_t 
/opt/syslog-ng/var/syslog-ng.persist
/usr/sbin/semanage fcontext -a -t syslogd_var_lib_t 
/opt/syslog-ng/var/run/syslog-ng.pid
/usr/sbin/semanage fcontext -a -t syslogd_var_lib_t 
/opt/syslog-ng/var/run/syslog-ng.ctl
/usr/sbin/semanage fcontext -a -t syslog_conf_t 
/opt/syslog-ng/etc/syslog-ng.conf
* Apply changes to file contexts:
restorecon -R /opt/syslog-ng/ /etc/init.d/syslog-ng

* save local.te:
--------------------------------
module sdi_syslog 1.0;

require
{
     type syslogd_t;
     type var_t;
     type bin_t;
     class process getsched;
     class file { read execute execute_no_trans };
     class dir write;
}

#============= syslogd_t ==============
allow syslogd_t bin_t:file { read execute execute_no_trans };
allow syslogd_t self:process getsched;
allow syslogd_t var_t:dir write;
--------------------------------

* Compile and install our local syslog-ng selinux policy:
checkmodule -M -m -o local.mod local.te
semodule_package -o local.pp -m local.mod
semodule -i local.pp

* If you had to update the mount options on /opt, reboot
* Otherwise, run:
rm -f /dev/log
service syslog-ng restart
* Verify that syslog is running in syslogd_t type domain and that 
/dev/log is created as type devlog_t

...

FYI, the local policy is probably too permissive as Stephen mentioned in 
one of the previous posts.  Hopefully, I will find time to fix that 
eventually at which point I will try to remember to post an update. 
Until then though, this is the best I've got.

Suggestions are welcomed.

Thanks so much for the help!

[Daniel J Walsh]

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

On 03/21/2013 03:54 PM, Daniel Neuberger wrote:
>  On 03/19/2013 04:01 PM, Stephen Smalley wrote:
> > We followed the existing convention that nosuid disables security state 
> > changes for executables in that filesystem and applied it to SELinux 
> > security contexts in addition to the existing restrictions on 
> > setuid/setgid executables.  If you didn't trust setuid/setgid bits from 
> > that filesystem, why would you trust security contexts from it?  But in 
> > retrospect, it might have been better to have a separate flag for that 
> > purpose.
>  
>  Interesting.  I guess I can see both sides.  In our case, we have a
>  separate requirement to specify nosuid, but now we have to justify not
>  doing so in order to keep SELinux working.  So it makes sense to me from a
>  technical standpoint, but decisions aren't always made that way.  So I
>  agree that having a separate flag would be useful to allow more
>  flexibility.  Thanks for the explanation.
>  
>  One more question.  I tried putting my semanage calls to update the file 
>  contexts in a custom rpm depending on the selinux-policy-targeted rpm. In
>  the rpm scriptlet, I first made all the semanage calls and then called
>  restorecon on the appropriate paths so that the new file contexts would be
>  applied without having to relabel the entire file system.  This all works
>  except when the rpm is installed by anaconda during a kickstart install.
>  In that case, I have to run restorecon again during kspost or manually
>  after the install.  Any ideas why or suggestions for a better solution?
>  
>  For those interested, here is a summary of the complete solution to get
>  the syslog-ng daemon as installed by the balabit rpms on RHEL 5 working
>  with selinux:
>  
>  * Make sure nosuid is not set on /opt * Update file contexts: 
>  /usr/sbin/semanage fcontext -a -t syslogd_script_exec_t
>  /etc/init.d/syslog-ng /usr/sbin/semanage fcontext -a -t syslogd_exec_t
>  /opt/syslog-ng/sbin/syslog-ng /usr/sbin/semanage fcontext -a -t var_run_t
>  /opt/syslog-ng/var/run /usr/sbin/semanage fcontext -a -t syslogd_var_lib_t 
>  /opt/syslog-ng/var/syslog-ng.persist /usr/sbin/semanage fcontext -a -t
>  syslogd_var_lib_t /opt/syslog-ng/var/run/syslog-ng.pid /usr/sbin/semanage
>  fcontext -a -t syslogd_var_lib_t /opt/syslog-ng/var/run/syslog-ng.ctl 
>  /usr/sbin/semanage fcontext -a -t syslog_conf_t
>  /opt/syslog-ng/etc/syslog-ng.conf 
You pobably want to run all these commands within
a transaction.

Something like

semanage -i << _EOF
fcontext -a -t syslogd_script_exec_t /etc/init.d/syslog-ng
fcontext -a -t syslogd_exec_t /opt/syslog-ng/sbin/syslog-ng
...
_eof

Should make it run a lot faster.
>  * Apply changes to file contexts: restorecon -R /opt/syslog-ng/
>  /etc/init.d/syslog-ng
>   
I have no idea why this would fail unless the restorecon is failing for some
reason.  I guest I would put selinux-policy-base in a Requires(Post) block to
make sure it is installed.


>  * save local.te: -------------------------------- module sdi_syslog
> 1.0;
>  
>  require { type syslogd_t; type var_t; type bin_t; class process getsched; 
>  class file { read execute execute_no_trans }; class dir write; }
>  
>  #============= syslogd_t ============== allow syslogd_t bin_t:file { read
>  execute execute_no_trans }; allow syslogd_t self:process getsched; allow
>  syslogd_t var_t:dir write; --------------------------------
>  
>  * Compile and install our local syslog-ng selinux policy: checkmodule -M -m
>  -o local.mod local.te semodule_package -o local.pp -m local.mod semodule -i
>  local.pp
>  
>  * If you had to update the mount options on /opt, reboot * Otherwise, run: 
>  rm -f /dev/log service syslog-ng restart * Verify that syslog is running in
>  syslogd_t type domain and that /dev/log is created as type devlog_t
>  
>  ..
>  
>  FYI, the local policy is probably too permissive as Stephen mentioned in
>  one of the previous posts.  Hopefully, I will find time to fix that
>  eventually at which point I will try to remember to post an update. Until
>  then though, this is the best I've got.
>  
>  Suggestions are welcomed.
>  
>  Thanks so much for the help!
>  
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
>   
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlFMex0ACgkQrlYvE4MpobOytwCgjxaxuI2evS8S5FwLVGKgwABE
> yQcAoKEepMB3x52L4Ugya33TibppT1dx
> =SaOR
> -----END PGP SIGNATURE-----