Wrong syslog-ng behaviour for PROGRAM macro and non-root file follow
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. 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. 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) Thank you in advance. Best Regards, Pavel
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
Greetings; I currently have syslog-ng.conf set up to place data into logs in the following way: /var/log/MyHosts/SambaServers/$FULLHOST.log When the logs are created, they are placed under: /var/log/MyHosts/SambaServers/samba-1.mynet.org/samba-1.mynet.org.log The contents for the hostname field in logs from samba-1 look like this: May 13 10:32:55 samba-1.mynet.org/samba-1.mynet.org Because of the double entry in syslog, all looks fine and logs are stored in nice neat folders named after the host that sent them, great. I have however a few MS Wintel servers that I am using Snare for sending syslog data to, and their logs look like: May 13 10:36:15 samba-2.mynet.org MSWinEventLog 1 Security As you can see, the logs from this host do not contain the hostname twice, therefore logs for this host are stored as: /var/log/MyHosts/SambaServers/samba-2.mynet.org.log I can create a rule like /var/log/MyHosts/SambaServers/$FULLHOST/$FULLHOST.log for just these hosts, but that will not solve my problem long term, especially as I am considering implementing Snare site-wide. Could someone please advise as to whether there is an easy fix for this, or should I cease using Snare? Thanks in advance, .vp
FYI I've modified Snares config to not enable syslog headers, and now my logs are going into a newly created directory, same as all others. The only difference now is that the hostname/domainname used before is not the same as what was previously being used. The former was dictated by the logs entry, the new one uses DNS to resolve. .vp From: wiskbroom@hotmail.com To: syslog-ng@lists.balabit.hu Date: Tue, 13 May 2008 10:48:31 -0400 Subject: [syslog-ng] Irregular Behaviour With Snare Agent (syslog-ng or Snare?) Greetings; I currently have syslog-ng.conf set up to place data into logs in the following way: /var/log/MyHosts/SambaServers/$FULLHOST.log When the logs are created, they are placed under: /var/log/MyHosts/SambaServers/samba-1.mynet.org/samba-1.mynet.org.log The contents for the hostname field in logs from samba-1 look like this: May 13 10:32:55 samba-1.mynet.org/samba-1.mynet.org Because of the double entry in syslog, all looks fine and logs are stored in nice neat folders named after the host that sent them, great. I have however a few MS Wintel servers that I am using Snare for sending syslog data to, and their logs look like: May 13 10:36:15 samba-2.mynet.org MSWinEventLog 1 Security As you can see, the logs from this host do not contain the hostname twice, therefore logs for this host are stored as: /var/log/MyHosts/SambaServers/samba-2.mynet.org.log I can create a rule like /var/log/MyHosts/SambaServers/$FULLHOST/$FULLHOST.log for just these hosts, but that will not solve my problem long term, especially as I am considering implementing Snare site-wide. Could someone please advise as to whether there is an easy fix for this, or should I cease using Snare? Thanks in advance, .vp
Dear Bazsi, 1) Regarding the "unsafe" macro $PROGRAM, I would recommened addition of some option or flag , where you can turn on a replacement of unsafe characters in destination and also set the new target character as you like. 2) Regarding the drop of root privileges - leave it as it is now, just remember to write it into the documentation. (Maybe future desing may change this.) Best Regards, Pavel -----Original Message----- From: syslog-ng-bounces@lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: Tuesday, May 13, 2008 2:48 PM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] Wrong syslog-ng behaviour for PROGRAM macro and non-root file follow 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 ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html
On Thu, 2008-05-15 at 12:04 +0000, Behal, Pavel wrote:
Dear Bazsi,
1) Regarding the "unsafe" macro $PROGRAM, I would recommened addition of some option or flag , where you can turn on a replacement of unsafe characters in destination and also set the new target character as you like.
fair enough.
2) Regarding the drop of root privileges - leave it as it is now, just remember to write it into the documentation. (Maybe future desing may change this.)
Cced the documentation team on this one. -- Bazsi
participants (3)
-
Balazs Scheidler
-
Behal, Pavel
-
wiskbroom＠hotmail.com