[syslog-ng] Wrong syslog-ng behaviour for PROGRAM macro and non-root file follow

[Balazs Scheidler]

On Mon, 2008-05-12 at 11:58 +0000, Behal, Pavel wrote:
> Dear Developers,
> 
> I would like to report two wrong behaviors of syslog-ng. I have received them while running the 2.1.alpha1 version, but from the GIT repository I see, it has not been reported nor fixed yet:
> 
> 1) Possible problems in destination macro $PROGRAM
> 
> I use macro $PROGRAM in some destination file name templates to better identify source messages. Unfortunately, sometimes the $PROGRAM macro in syslog message is filled with file name with full path. (Like /usr/bin/xxxxx.)  This leads to the situation that syslog-ng tries to write to the complete different path than expected. And depending on the "create_dirs" option, new directories can be also created.
> 
> Generically we can say, there is a problem that invalid unix filename/filepath characters can be passed to syslog and create a technical or security issue. (It is not only a problem of / slash, but any special unix character like . or ~ can change the path meaning.)
> 
> I do not have any "best" solution now to offer, but I would like to ask you to validate this behaviour and extended the design so it is protected against such unexpected destination path manipulation.

The contents of the $PROGRAM variable may not be completely trusted as
that's provided by the client program that constructed the message.

The '~' resolution is provided by the shell, thus it does not work
inside syslog-ng, it'd be expanded as a literal '~', not to your home
directory.

Syslog-ng refuses to open any file that has '..' in its name, thus it is
generally believed that you cannot escape the root of your destination
directory, albeit it is possible to create files/paths inside that.

> 
> 2) Unexpected initialization of followed file sources
> 
> I run a special instance of the syslog-ng under non-root configuration. It is started as root but with a "-u syslogng" option to switch to other user. And it is used to follow some file sources to be transferred to the central log server. It works fine, but only until the log is rotated in a wrong way. Let's explain: The log file's permissions has to be changed manually always after the rotation, to be readable by other users. This is my part, but for some reason, I have had an error there and I have received this scenario:
> 
> - Initial status: the log permissions are private, the syslog-ng is unable to read the log -> this is expected.
> - I have restarted the syslog-ng instance due some reconfiguration -> OOPS, it has found and opened the -> this is unexpected!
> - The log is followed successfully, even with private permissions!
> - But, only until it is rotated again - I expect the file handle is lost finally
> 
> So from my view: When a syslog-ng with -u option starts, it first opens all logs as root and after that it switches its effective UID:GID as required. This is nice feature, but a little bit unexpected.

This is true, the reason that it needs root privileges to initialize its
configuration in most cases (open /proc/kmsg, open privileged ports,
etc).

> 
> I would like to ask you if you can again check the initialization part of syslog-ng and clean the design, so it either:
> - always opens every (file) source under the non-root user (more secure, but worse for me)
> - or always re-opens the followed (file) sources with original higher root privileges (less secure, but nice and easier for me to read private application logs)

Currently the user/group switching feature is there, however it is
limited in many ways. For instance syslog-ng is unable to raise its own
privilege level for reloading the configuration. Thus if you have any
sources that require root privileges it will be initilialized fine on
startup, and then upon the receipt of the HUP signal it'll fail.

It'd require a great deal of reorganization to support regaining of
permissions. It'd be easier to drop root privileges earlier, but that
would break people's current configuration who rely on the current
behaviour (and as it seems even you do).

I might add an --early-drop-root-privs command line option, but I doubt
anyone would use that.

Opinions?

-- 
Bazsi