Ubuntu

Various problems running syslogd with "-u syslog" option

Reported by Graeme Hewson on 2007-06-12
264
Affects Status Importance Assigned to Milestone
sysklogd (Ubuntu)
Medium
Canonical Server Team

Bug Description

Binary package hint: sysklogd

Ubuntu tries to run syslogd with uid syslog rather than root, for improved security. As found in bug #103232, in fact it still runs as root by default because /etc/default/syslogd, sourced from /etc/init.d/sysklogd, doesn't set $SYSLOGD to the correct value.

After correcting this problem and running syslogd with "-u syslog", I have found various other problems. The primary problem is that after the log files are rotated (by /etc/cron.[daily|weekly]/sysklogd), nothing is recorded: this is due to a permissions issue. Here's the description of the -u option in syslogd(8):

> The syslogd daemon runs with full root privileges by default. If
> you specify this option, the daemon will drop its privileges to
> the given user (and the primary group of this user) before
> starting up logging. This greatly reduces the potential impact
> of exploitable security holes in syslogd.

> syslogd will still open all log files as root at startup. How‐
> ever, after receiving a SIGHUP signal (which causes the daemon
> to restart) the log files will be reopened as the non-privileged
> user which fails if the log files are only writeable by root. If
> you need to restart the daemon using the signal, then you have
> to adapt the permissions of your log files to be writeable by
> the specified user (or its primary group).

The daily/weekly (ana)cronjobs issue:

/etc/init.d/sysklogd reload-or-restart

which in Feisty issues a SIGHUP signal (in earlier Ubuntu releases, the sysklogd script stops and restarts syslogd). This means, according to the second paragraph of the above description, that the log files aren't writable since they're owned by root, so nothing further gets recorded by syslogd.

The simplest fix for most current users, I would think, is always to run sydlogd as root. Let's persist, though.

The man page suggests "adapting" the permissions. The (ana)cronjobs issue:

savelog -g adm -m 640 -u root ...

These options are wrong because they don't match the -u set in the now corrected /etc/default/syslogd (and the implicit -g). If we correct these options, syslogd should work correctly after a SIGHUP. However, it doesn't make a lot of sense to have the first set of files created after boot be owned by root, but later files be owned by syslog. It would make more sense to modify syslogd to create the first set of files as syslog too. I've looked at the source, and it seems like a simple change near the first call to init().

There's still a further problem, a security issue, not related to running with uid syslog. syslogd(8), under BUGS, says:

> Syslogd doesn’t change the filemode of opened logfiles at any stage of
> process. If a file is created it is world readable. If you want to
> avoid this, you have to create it and change permissions on your own.
> This could be done in combination with rotating logfiles using the
> savelog(8) program that is shipped in the smail 3.x distribution.
> Remember that it might be a security hole if everybody is able to read
> auth.* messages as these might contain passwords.

And yes, when syslogd starts after boot, auth.log doesn't exist, and syslogd creates it world readable. After that, savelog touches new files with mode 640 and chmods existing files to mode 640, but for the first week after boot, auth.log is world-readable, I believe.

Perhaps syslogd should not create world-readable files by default, or should have a -m option to set the mode. Perhaps too /var/log/ shouldn't be world-readable (it isn't in Red Hat).

Related branches

Graeme Hewson (ghewson) wrote :

Sorry, the penultimate paragraph above is probably wrong, since auth.log would normally exist at boot time, with mode 640.

Markus Schlager (m-slg) wrote :

Thanx a lot for your explanations, Graeme!

I can confirm this on our server, running dapper-lts. We're experiencing these problems since last Friday, 15.6.2007. The consequences are quite serious. Since we're using an openLDAP-Server on this machine for user-authentification, this bug in /etc/cron.daily/sysklogd
 disables any login to this machine - neither via ssh nor locally. Communication with postfix (port 25) isn't possible any more either. The only way to get out of this situation is a hardware-reset! After reboot everything works fine - until the next run of /etc/cron.daily/sysklogd. Hence we disabled /etc/cron.daily/sysklogd for the moment.

Markus Schlager (m-slg) wrote :

better workaround for the moment:
changed SYSLOGD=" -u syslog" into SYSLOGD=" " in /etc/init.d/sysklogd.

Meanwhile the computer wouldn't even halt nor boot with this option enabled.

Matt Zimmerman (mdz) wrote :

I've confirmed this behaviour here. Each and every time that syslogd is reloaded (including by cron.daily), all logging ceases, as it fails to open all of its log files.

Changed in sysklogd:
importance: Undecided → Critical
status: New → Triaged
Matt Zimmerman (mdz) wrote :
Jörn Dreyer (j.dreyer) wrote :

We can confirm this on dapper lts. Exactly the same behaviour as Markus Schlager reported in https://bugs.launchpad.net/ubuntu/+source/sysklogd/+bug/120085/comments/2

Changed in sysklogd:
assignee: nobody → ubuntu-server

This problem doesn't affect the default configuration. The default
configuration file doesn't mention the option to change the user under
which the syslogd daemon is running.
The comment in the init script may be removed as it's misleading.

  importance low

Changed in sysklogd:
importance: Critical → Low
Jörn Dreyer (j.dreyer) wrote :

I disagree ... the problem is that in dapper ther is no /etc/default/syslogd. The problem described by Markus Schlager and confirmed by me still makes it quite critical I think.

On Wed, Sep 05, 2007 at 09:07:06PM -0000, Mathias Gug wrote:
>
> This problem doesn't affect the default configuration. The default
> configuration file doesn't mention the option to change the user under
> which the syslogd daemon is running.
> The comment in the init script may be removed as it's misleading.

What I think happened in my case is that I used to have SYSLOGD="-r" in
/etc/default/syslogd, and since I no longer needed remote logging, I simply
commented this out.

This had the unexpected side effect of breaking all of my logging.
Adjusting the priority appropriately, leaving milestone.

--
 - mdz

Changed in sysklogd:
importance: Low → Medium
Mathias Gug (mathiaz) wrote :

It seems that there are two issues here, one for gutsy and one for dapper.

The issue that was reported is for gutsy and shouldn't apply for dapper.

In dapper, the reload action in the init script stops then starts the syslog daemon. In gutsy, the reload action in the init script sends a HUP signal, which is the reason why it has problem reopening files when run under the syslog user.

For dapper users, did you change the cron script or the init script ?

Jörn Dreyer (j.dreyer) wrote :

I used the workaround Markus Schlager proposed:
changed SYSLOGD=" -u syslog" into SYSLOGD=" " in /etc/init.d/sysklogd

On Thu, Sep 06, 2007 at 03:44:23PM -0000, Jörn Dreyer wrote:
> I used the workaround Markus Schlager proposed:
> changed SYSLOGD=" -u syslog" into SYSLOGD=" " in /etc/init.d/sysklogd
>

I'm trying to figure out what change caused you the problem. Is it a
fresh install of dapper ? Was it working before but started to fail after an
upgrade ?

Mathias Gug (mathiaz) wrote :

I've attached a debdiff that should fix the issue in gutsy.

I've looked into the suggestion of dropping the root privilege before init. However it won't work as init parses the configuration file to open the log files. If network logging is required (which is only known after the configuration file is parsed), syslogd needs to bind to a system port, which can only be done as root.

Instead, I've patched the init script to start syslogd with the -u option. Before starting syslogd, all the log files that syslogd will open have their ownership fixed. That should fix the issue, as long as the init script is used to start/stop/reload syslogd.

Markus Schlager (m-slg) wrote :

On Thu, 6 Sep 2007, Mathias Gug wrote:

> I'm trying to figure out what change caused you the problem. Is it a
> fresh install of dapper ?

Yes. (i.e. no upgrade from breezy)

> Was it working before but started to fail after an
> upgrade ?
>

Yes indeed. In our case it started to fail on Saturday, June 16th due to
the call of /etc/cron.daily/sysklogd.

Markus
-----------------------------------------------
 Markus Schlager m.slg(at)gmx.de

Mathias Gug (mathiaz) wrote :

On Thu, Sep 06, 2007 at 09:34:05PM -0000, Markus Schlager wrote:
> Yes indeed. In our case it started to fail on Saturday, June 16th due to
> the call of /etc/cron.daily/sysklogd.
>

Could you figure out which packages have been upgraded around that time
?

On Thu, Sep 06, 2007 at 09:32:48PM -0000, Mathias Gug wrote:
> I've attached a debdiff that should fix the issue in gutsy.
>
> I've looked into the suggestion of dropping the root privilege before
> init. However it won't work as init parses the configuration file to
> open the log files. If network logging is required (which is only known
> after the configuration file is parsed), syslogd needs to bind to a
> system port, which can only be done as root.
>
> Instead, I've patched the init script to start syslogd with the -u
> option. Before starting syslogd, all the log files that syslogd will
> open have their ownership fixed. That should fix the issue, as long as
> the init script is used to start/stop/reload syslogd.
>
> ** Attachment added: "sysklogd_1.4.1-21ubuntu3.debdiff"
> http://launchpadlibrarian.net/9156609/sysklogd_1.4.1-21ubuntu3.debdiff

Shouldn't the cron script be fixed to set correct ownership as well?

--
 - mdz

Mathias Gug (mathiaz) wrote :

I've attached a new debdiff that also fixes the weekly and daily cron script from sysklogd.

Matt Zimmerman (mdz) wrote :

On Fri, Sep 07, 2007 at 11:09:12PM -0000, Mathias Gug wrote:
> I've attached a new debdiff that also fixes the weekly and daily cron
> script from sysklogd.

Looks good. The only thing I question is whether it's a good idea to change
the default this late in the release cycle, as there may be other bugs
lurking.

--
 - mdz

Changed in sysklogd:
assignee: ubuntu-server → canonical-server
Henrik Nilsen Omma (henrik) wrote :

Moving milestone to beta.

This was raised at the meeting, who is going to make the call on whether we change this?

Mathias Gug (mathiaz) wrote :

I've attached a new debdiff that checks whether the regex to extract a user will match or not.

Mathias Gug (mathiaz) wrote :

Attached another version which makes more sense.

Martin Pitt (pitti) wrote :

In your cron.{daily,weekly} modifications:

+[ -z "${USER}" ] && USER="root"

you should append || true, so that the script does not bail out if $USER is not zero. That's only an issue if the script is under set -e, but it's generally more robust.

Martin Pitt (pitti) wrote :

Approved for Gutsy. Up until dapper, running it as system user worked fine and we still have enough time to test it properly and fix it further, if necessary.

Mathias Gug (mathiaz) wrote :

I've added a new debdiff that fixes the above issue.

Mathias Gug (mathiaz) wrote :

sysklogd (1.4.1-21ubuntu3) gutsy; urgency=low

  * debian/rc:
    * Fix syslogd to run as syslog user. Fix LP: #120085.
    * Add comment that points to /etc/default/syslogd to set default options.
      Fix LP: #103232.
  * debian/cron.daily, debian/cron.weekly:
    * Rotate logs with the correct ownership.

 -- Mathias Gug <email address hidden> Fri, 07 Sep 2007 18:57:55 -0400

Changed in sysklogd:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Bug attachments