Don't run as root

Bug #388608 reported by Michael Terry on 2009-06-17
This bug affects 1 person
Affects Status Importance Assigned to Milestone
rsyslog (Ubuntu)

Bug Description

Binary package hint: rsyslog

Right now rsyslog always runs as root. Ideally it wouldn't.

In particular, three things need to happen:
1) Bug 250827 needs to be fixed, where the package creates the syslog user.
2) We need to backport the upstream support for dropping privileges or update to 4.1.1 or later.
3) We need to do something about reading /proc/kmsg. sysklogd handled it by starting a dd process that shoveled the data to a syslog-readable location. We may need a similar trick.

Related branches

Michael Terry (mterry) wrote :

Here's an initial debdiff that does this as well as cleanly upgrades from sysklogd to rsyslog. There's still an issue with kern.log that I'm looking into. This is not done yet, this is just an alpha preview. :)

Changed in rsyslog (Ubuntu):
assignee: nobody → Michael Terry (mterry)
status: New → In Progress
Michael Terry (mterry) wrote :

OK, better version that switches to syslog user earlier to avoid issue with the kmsg pipe not giving us any data if we read from it before switching uid/gid.

So things this patch does:
1) Backports the 'DropPriv' config values from upstream
2) Copies the dd-shovels-proc-kmsg-to-readable-location logic from sysklogd and adds a config value to change klog location
3) Handles upgrade from sysklogd by doing the following:
   A) Splits rsyslog.conf into two parts: config stuff and rules
   B) If we're upgrading to this version or later and /etc/syslog.conf exists *and* is modified by user, then copy it to /etc/rsyslog.d/default.conf
   C) Merge our default rules into /etc/rsyslog.d/default.conf using ucf

Changed in rsyslog (Ubuntu):
assignee: Michael Terry (mterry) → nobody
status: In Progress → Confirmed
Changed in rsyslog:
status: Unknown → Confirmed
Michael Terry (mterry) wrote :

Third time's the charm. After talking with upstream, I realized we need to initialize modules while still root (so that they can grab privileged port or whatnot). So here I split out the initialization and the running of modules, so that now they are only run after privileges are dropped, but initialized beforehand.

Michael Terry (mterry) wrote :

Here are a couple more improvements, from suggestions by the Debian maintainer:
1) Add comment in rsyslog.conf noting that the rules are in /etc/rsyslog.d
2) Don't parse /var/lib/dpkg/status directly, use dpkg-query
3) Rename default.conf to 50-default.conf

Andrew Mitchell (ajmitch) wrote :

It looks like Karmic just got rsyslog 4.2.0 in a case of spectacular timing. Would you mind reviewing & updating your changes with respect to this new version, and then resubscribing ubuntu-universe-sponsors?

Changed in rsyslog:
status: Confirmed → Fix Released
Michael Terry (mterry) wrote :

Ah, well. Here's the 4.2.0 debdiff. Basing off 4.2.0 meant I could drop the 'backport of DropUserPriv' bit of the patch, which is nice.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rsyslog - 4.2.0-1ubuntu1

rsyslog (4.2.0-1ubuntu1) karmic; urgency=low

  * Run as rsyslog:rsyslog (LP: #250827, LP: #388608)
    - debian/control: Depend on adduser
    - debian/rsyslog.postinst: Create syslog user
    - debian/rsyslog.postrm: Delete syslog user on purge
    - debian/rsyslog.conf: Use DropPriv config fields
  * Allow reading /proc/kmsg when non-root
    - debian/rsyslog.init: Spawn a dd instance that shovels the /proc/kmsg
      data to a pipe that rsyslog can read (based on Martin Pitt's similar
      change to sysklogd).
    - debian/patches/deroot.patch: Support a KLogPath config field
      to change where the klog plugin looks and only start input modules
      after we drop privileges, as reading when root interferes with
      future reads as syslog.
    - debian/rsyslog.conf: Use KLogPath field to point to dd pipe
  * Cleanly upgrade from sysklogd
    - debian/default.conf, debian/rsyslog.conf:
      Break out the default rules into their own config file
    - debian/rsyslog.install: Install it in /usr/share/rsyslog
    - debian/rsyslog.postinst: If present, copy /etc/syslog.conf into
      /etc/rsyslog.d/default.conf. Then merge our own default.conf

 -- Michael Terry <email address hidden> Mon, 29 Jun 2009 08:37:43 -0400

Changed in rsyslog (Ubuntu):
status: Confirmed → Fix Released
Juliano Ravasi (jravasi) wrote :

> 2) Copies the dd-shovels-proc-kmsg-to-readable-location logic from sysklogd and adds a config value to change klog location

> * Allow reading /proc/kmsg when non-root
> - debian/rsyslog.init: Spawn a dd instance that shovels the /proc/kmsg
> data to a pipe that rsyslog can read (based on Martin Pitt's similar
> change to sysklogd).

Please, could this be reverted? This was an ugly hack that was used by sysklogd. It keeps another process running (dd) just copying data from one descriptor to another.

Rsyslog allows it to be run as root, set itself up, and then drop its privileges to another user. This is the same method that is used for at least three decades when processes should run as non-privileged users but still need to open some privileged files/ports (only at startup). Using dd to copy data from one pipe to another not only is unnecessary, it also adds another single point of failure.

In short, set $PrivDropToUser and $PrivDropToGroup to the syslog user, and just run rsyslog as root.

Juliano Ravasi (jravasi) wrote :

I just found that the reason for dd is that Linux doesn't allow reading from the /proc/kmsg open descriptor without root privileges (as opposed to restricting just the open() call). The syslog-ng that I was using until now used the CAP_SYS_ADMIN capability to keep access to /proc/kmsg after dropping root privileges. It seems that rsyslog isn't currently programmed to use this capability, so my previous suggestion wouldn't work.

For now I switched back to syslog-ng, so that I don't need the extra 'dd' process running and still run the syslog daemon as an unprivileged user.

Sorry for the noise.

Currently, rsyslog can not read the kernel log once it has dropped privileges.

There has been an interesting note on the Ubuntu bug tracker [1] which recommends using linux capabilities and CAP_SYS_ADMIN in particular. Thanks to Michael Biebl for making me aware of that posting. I've dug a bit and found a good entry article [2] that convinced me this is a good solution. I just don't have the time to do it now, but hopefully within the next two month.


Michael Biebl (mbiebl) on 2009-07-29
Changed in rsyslog:
status: Fix Released → Unknown
Changed in rsyslog:
status: Unknown → Confirmed

Further discussion with the Ubuntu folks made me know that they don't consider it a good idea, because that capability sill has a lot of power. Still I find it a useful addition, but I demote its priority. Something to be done when not much more is left ;)

Changed in rsyslog:
importance: Unknown → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.