MonitorWare Knowledge Base

Hello there

I was wondering if it is possible to get rsyslog to run as a different user, for instance rsyslog ... or to get it to write files to be owned by someone other than root. OR with other default permissions than 600

Cheers

Chakkerz

• Custom written rsyslog.conf?
• Maintenance Contract?
• Installation support?

erm ... found (just too late)

http://www.rsyslog.com/doc-rsconf1_filecreatemode.html

That doesn't get around the running not as root though

You should also look at $FileOwner, $FileGroup and the respective $Dir.. directives.

As for a different user, this is not yet implemented. It also currently has no priority, as I was told this is no longer an issue in the days of selinux. I personally have no hard opinion on it, just following general demand...

Rainer

erm .. yes ... SE Linux does get around the issue, that is true.

And (far from being an SE Linux expert, though i have completed the Red Hat training / certification on that one [alas i don't get to use it enough to become an expert]) i have to say that when a system can get itself into a tight enough knot where the setroubleshoot service can not start because selinux is blocking it, and when it does start it craters anyway. Or when relabelling all files at start up, or using restorecon or fixfiles yields files that are in the same directory and rotates of the same log file, created by the same *syslog daemon i feel that 1) i need to re-read my course notes, and 2) there are still some issues to be resolved.

That said, it worked extremely well during the course ... lord knows i may have screwed something else up.

Also, i don't think that anyone in their right mind, even after running in permissive mode without errors truly expects that they can turn on selinux and not have errors. SE Linux is great ... but it's far from flawless. And the tools to support it are also far from flawless. And the Documentation that ships with the distros ... is somewhat lacking.

... but you know what the hilarious aspect of this is? I disabled selinux yesterday because it kept resulting in crashing my multipathd service. Fingers crossed i find some time monday to sort out the selinux issue so i can re-enable it But darn do i want to use SElinux ... it would be nice to put that training to use

chakkerz

Yeah... I am not a SE Linux expert at all. I see that there is some usefulness in natively supporting running under non-root. But there are tons of other features waiting for implementation. So it becomes a matter of priorities. Priorities depend on what is often asked for.

For example: I am currently working on a real secure TLS mode, what will (probably) be followed by a real secure and real reliable TLS mode for RELP. Should I stop implementing TLS to do the user thing? Maybe... But practice tells me many have asked for TLS and so far one for the user. So guess what...

(This may also be viewed as a call to action for all those who would like see a "not root" capability in rsyslog - obviously priorities are dynamic ).

I am using rsyslog for centralized logging for a couple of servers and I was also looking for this feature.

The reason is not wanting to have software that is exposed on a public IP to be running as root. I do not know SE Linux at all - currently I'm using an ugly hack to have rsyslog be started as a separate "rsyslog" user with su. Since non-root users can't listen on ports under 1024, I have it listening on 1514 (both tcp and udp) with iptables rules to forward data from 514 to 1514 (again, both tcp and udp).

It's not so nice and requires custom setup, but it works. Support for dropping permissions, like Apache, would be very welcome of course .

Good Morning (Afternoon / Evening / Night)

I was pondering the security threat that rsyslog posses to its hosts by nature of it receptiveness. And i noted that the rsyslogd man page contains the following

3. The ext2 filesystem can be used which can be configured to limit
a certain percentage of a filesystem to usage by root only.
NOTE that this will require rsyslogd to be run as a non-root
process. ALSO NOTE that this will prevent usage of remote log-
ging on the default port since rsyslogd will be unable to bind
to the 514/UDP socket.

Which once again raises my question of how do you do that? or alternatively, you might want to edit the man page

cheers

chakkerz

PS.: I'm usually like this on a monday morning ... oh who am i kidding, always

chakkerz wrote:Good Morning (Afternoon / Evening / Night)

I was pondering the security threat that rsyslog posses to its hosts by nature of it receptiveness. And i noted that the rsyslogd man page contains the following

3. The ext2 filesystem can be used which can be configured to limit
a certain percentage of a filesystem to usage by root only.
NOTE that this will require rsyslogd to be run as a non-root
process. ALSO NOTE that this will prevent usage of remote log-
ging on the default port since rsyslogd will be unable to bind
to the 514/UDP socket.

Which once again raises my question of how do you do that? or alternatively, you might want to edit the man page

cheers

chakkerz

Well, you can simply run it under a different user account. Rsyslogd does not really care if it is root or not. It just can't bind to privileged ports if it isn't root. So, yes, you can run it as any user you like. What it can not do is start as root and then drop privileges. Running alsways as e.g. "rsyslog" user is fine.

HTH
Rainer

touche

Interesting, i'll look into that some more mayhaps ... i've sort of resigned myself to running as root ... there is a bug in RHEL which means standard user's cronjobs ... may not run ...

but i need more time to check that out, so your suggestion is right up top

Thanks for pointing that out

chakkerz

anyhow, the discussion makes me begin to think providing the capability to drop privileges. I will see how this could be done. One thing that concerns me is HUPing the syslogd. At that point, I would need to regain higher privileges (because I would need to bind to the privileged ports). As of my understanding, this is not possible. I fear it becomes a bit inconsistent if I disable HUPing when running as a different user...

Rainer

Hi there,

not much has been said on this since almost 1.5 years ago and I'd like to know if something has been done towards this feature because it's an important/needed change in rsyslog if it's not implemented yet...

For example, syslog-ng has a switch which allows to drop privileges to non-root users: syslog-ng -u foo ...

Do we have something equivalent in rsyslog already?


Cheers

Hello,

it's me again

I was reading here http://www.rsyslog.com/doc-droppriv.html that it's now possible to run as a different user, so I quickly upgraded to rsyslog 4.2.0 and started to add the new configuration directives to the rsyslog.conf file... I created the rsyslog group and rsyslog user and added the following lines:

---
$PrivDropToUser rsyslog
$PrivDropToGroup rsyslog
$umask 0000
$FileCreateMode 0640
$FileGroup rsyslog
---

then restarted rsyslog and... BOOM! /var/log/messages gets quickly flooded with this:

2009-08-19T07:51:37.537666-04:00 logserver kernel: Cannot read proc file system: 1 - Operation not permitted.
2009-08-19T07:51:37.537769-04:00 logserver kernel: Cannot read proc file system: 1 - Operation not permitted.
2009-08-19T07:51:37.537870-04:00 logserver kernel: Cannot read proc file system: 1 - Operation not permitted.
2009-08-19T07:51:37.537970-04:00 logserver kernel: Cannot read proc file system: 1 - Operation not permitted.
2009-08-19T07:51:37.538070-04:00 logserver kernel: Cannot read proc file system: 1 - Operation not permitted.
2009-08-19T07:51:37.538168-04:00 logserver kernel: Cannot read proc file system: 1 - Operation not permitted.

same results occur with $PrivDropToUserID...

For the sake of testing I tried to start rsyslog as non-root:
---
# su - rsyslog -c "/etc/init.d/rsyslog start"
Starting system logger: Can't open or create /var/run/syslogd.pid.
Can't write pid.
---

which seems to me like a catch-22: the file is created when rsyslog starts but it cannot start due to permissions, which can only be changed once the file is there... and I shall not change the permissions on /var/lock/subsys...

Anyway, this is the farthest point I've reached so far with $PrivDropToGroup rsyslog:
---
2009-08-19T07:51:49.482847-04:00 logserver kernel: imklog 4.2.0, log source = /proc/kmsg started.
2009-08-19T07:51:49.483201-04:00 logserver rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="24443" x-info="http://www.rsyslog.com"] (re)start
2009-08-19T07:51:49.483821-04:00 logserver rsyslogd: rsyslogd's groupid changed to 36034
---

which still yields in rsyslog running as root:
---
# ps -ef | grep rsyslog
root 24507 1 0 08:04 ? 00:00:00 rsyslogd -c 4 -x
---

Any suggestions?

Thanks!!

I think the doc states (it should) that imklog can not work with dropped privileges. A work-around is to run two instances, one with dropped privileges listening to the network port and one without taking care of imklog. There has been suggestions to solve the situation by using capabilities, which I will look into some time in the future. It looks like a good way to do it.

This link may also be useful:

http://wiki.rsyslog.com/index.php/Chroot_support