pykolab daemons writing world-wide writeable pidfiles
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	dhoffend
	Nov 15 2019, 11:26 AM

Description

The daemon writes its pidfile using os.umask(0) which results in world-wide-writeable pidfiles. The start-stop-daemon doesn't want to trust the pidfile content and therefore ignores a stop attemp.

Warnings:

Nov 15 01:55:43 kolab kolab-saslauthd[16880]: start-stop-daemon: matching on world-writable pidfile /run/kolab-saslauthd/kolab-saslauthd.pid is insecure
Nov 15 01:55:45 kolab wallace[16995]: start-stop-daemon: matching on world-writable pidfile /run//wallaced/wallaced.pid is insecure

Example stop attemp with pidfile mode 0666

root@kolab ~ # systemctl start kolab-saslauthd

root@kolab ~ # systemctl status kolab-saslauthd
● kolab-saslauthd.service - LSB: Start/Stop the Kolab SASL authentication daemon
   Loaded: loaded (/etc/init.d/kolab-saslauthd; generated)
   Active: active (running) since Fri 2019-11-15 10:05:30 CET; 5s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 14162 ExecStart=/etc/init.d/kolab-saslauthd start (code=exited, status=0/SUCCESS)
    Tasks: 1 (limit: 4699)
   Memory: 12.1M
   CGroup: /system.slice/kolab-saslauthd.service
           └─14172 /usr/bin/python /usr/sbin/kolab-saslauthd -l warning --fork

Nov 15 10:05:30 kolab systemd[1]: Starting LSB: Start/Stop the Kolab SASL authentication daemon...
Nov 15 10:05:30 kolab systemd[1]: Started LSB: Start/Stop the Kolab SASL authentication daemon.

root@kolab ~ # ls -la /run/kolab-saslauthd/kolab-saslauthd.pid
-rw-rw-rw- 1 kolab kolab 6 Nov 15 10:05 /run/kolab-saslauthd/kolab-saslauthd.pid

root@kolab ~ # systemctl stop kolab-saslauthd

root@kolab ~ # systemctl status kolab-saslauthd
● kolab-saslauthd.service - LSB: Start/Stop the Kolab SASL authentication daemon
   Loaded: loaded (/etc/init.d/kolab-saslauthd; generated)
   Active: inactive (dead) since Fri 2019-11-15 10:05:46 CET; 2s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 14162 ExecStart=/etc/init.d/kolab-saslauthd start (code=exited, status=0/SUCCESS)
  Process: 14233 ExecStop=/etc/init.d/kolab-saslauthd stop (code=exited, status=0/SUCCESS)
    Tasks: 1 (limit: 4699)
   Memory: 12.3M
   CGroup: /system.slice/kolab-saslauthd.service
           └─14172 /usr/bin/python /usr/sbin/kolab-saslauthd -l warning --fork

Nov 15 10:05:30 kolab systemd[1]: Starting LSB: Start/Stop the Kolab SASL authentication daemon...
Nov 15 10:05:30 kolab systemd[1]: Started LSB: Start/Stop the Kolab SASL authentication daemon.
Nov 15 10:05:46 kolab systemd[1]: Stopping LSB: Start/Stop the Kolab SASL authentication daemon...
Nov 15 10:05:46 kolab kolab-saslauthd[14233]: start-stop-daemon: matching on world-writable pidfile /run/kolab-saslauthd/kolab-saslauthd.pid is insecure
Nov 15 10:05:46 kolab systemd[1]: kolab-saslauthd.service: Succeeded.
Nov 15 10:05:46 kolab systemd[1]: Stopped LSB: Start/Stop the Kolab SASL authentication daemon.

Example stop attempt with fixed pidfile mode:

root@kolab ~ # systemctl start kolab-saslauthd

root@kolab ~ # systemctl status kolab-saslauthd
● kolab-saslauthd.service - LSB: Start/Stop the Kolab SASL authentication daemon
   Loaded: loaded (/etc/init.d/kolab-saslauthd; generated)
   Active: active (exited) since Fri 2019-11-15 10:07:24 CET; 3s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 14678 ExecStart=/etc/init.d/kolab-saslauthd start (code=exited, status=0/SUCCESS)

Nov 15 10:07:24 kolab systemd[1]: Starting LSB: Start/Stop the Kolab SASL authentication daemon...
Nov 15 10:07:24 kolab kolab-saslauthd[14678]: start-stop-daemon: matching only on non-root pidfile /run/kolab-saslauthd/kolab-saslauthd.pid is insecure
Nov 15 10:07:24 kolab systemd[1]: Started LSB: Start/Stop the Kolab SASL authentication daemon.

root@kolab ~ # chmod 644 /run/kolab-saslauthd/kolab-saslauthd.pid

root@kolab ~ # ls -la /run/kolab-saslauthd/kolab-saslauthd.pid
-rw-r--r-- 1 kolab kolab 6 Nov 15 10:05 /run/kolab-saslauthd/kolab-saslauthd.pid

root@kolab ~ # systemctl stop kolab-saslauthd

root@kolab ~ # systemctl status kolab-saslauthd
● kolab-saslauthd.service - LSB: Start/Stop the Kolab SASL authentication daemon
   Loaded: loaded (/etc/init.d/kolab-saslauthd; generated)
   Active: inactive (dead) since Fri 2019-11-15 10:07:41 CET; 2s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 14678 ExecStart=/etc/init.d/kolab-saslauthd start (code=exited, status=0/SUCCESS)
  Process: 14801 ExecStop=/etc/init.d/kolab-saslauthd stop (code=exited, status=0/SUCCESS)

Nov 15 10:07:24 kolab systemd[1]: Starting LSB: Start/Stop the Kolab SASL authentication daemon...
Nov 15 10:07:24 kolab kolab-saslauthd[14678]: start-stop-daemon: matching only on non-root pidfile /run/kolab-saslauthd/kolab-saslauthd.pid is insecure
Nov 15 10:07:24 kolab systemd[1]: Started LSB: Start/Stop the Kolab SASL authentication daemon.
Nov 15 10:07:41 kolab systemd[1]: Stopping LSB: Start/Stop the Kolab SASL authentication daemon...
Nov 15 10:07:41 kolab systemd[1]: kolab-saslauthd.service: Succeeded.
Nov 15 10:07:41 kolab systemd[1]: Stopped LSB: Start/Stop the Kolab SASL authentication daemon.

Details

Ticket Type: Task

Revisions and Commits

rP pykolab
	D847	rP17db4f8027dd restore system umask after fork (fix T5659)

Related Objects

Mentioned Here: D847: restore system umask after fork (fix T5659)

Event Timeline

dhoffend created this task.Nov 15 2019, 11:26 AM

dhoffend updated the task description. (Show Details)

dhoffend added a project: PyKolab.

dhoffend added a subscriber: PyKolab Developers.

dhoffend updated the task description. (Show Details)Nov 15 2019, 11:41 AM

See Debian Bug Entry: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921016

The start-stop-daemon has been changed:

dpkg's changelog.Debian says:
 * start-stop-daemon: Check whether standalone --pidfile use is secure.
    Prompted by Michael Orlitzky <michael@orlitzky.com>.

the regular changelog is more verbose:
------------------------
commit bc9736f6feae7625cc5ec063ea1b27d51a5f9317
Author: Guillem Jover <guillem@debian.org>
Date:   Sat Sep 22 12:12:05 2018 +0200

    s-s-d: Check whether standalone --pidfile use is secure

    If we are only matching on the pidfile, which is owned by a non-root
    user, and we are running as a root user then this is a security risk,
    and the contents cannot be trusted, because the daemon might have been
    compromised which would allow modifying the pid within.

    If we are then calling start-stop-daemon as a privileged user, that
    would allow acting on any PID in the system.

    Prompted-by: Michael Orlitzky <michael@orlitzky.com>
    Ref: https://redmine.kannel.org/issues/771
------------------------

We must make sure the pidfile is secure otherwise start-stop-daemon will not interact with the daemon.

The mentioned workaround works for debian 10 but not good on debian 9 (runs into 30s timeout before killing it).

Solution:

When the daemon runs as kolab user and the pidfile is owned by kolab, we must use start-stop-daemon with --user $USER option
The write_pid function must be changed so we don't create insecure pidfiles

I'll revert/fix the obs package and make sure 1) the --pidfile and --user arguments are in line with the requirements. the umask fix must be changed in python code

dhoffend updated the task description. (Show Details)Nov 15 2019, 11:51 AM

Uploaded D847

The individual directories in /run/ are secured, so there's little need to secure the files within them.

That being said, no apparent regressions, so we'll move forward with it.

vanmeeuwen added a commit: rP17db4f8027dd: restore system umask after fork (fix T5659).Nov 18 2019, 12:05 PM