Bug#680660: collectd - runs as root without apparent reason
On Sun, Jul 08, 2012 at 02:50:02PM +0200, Sebastian Harl wrote: On Sat, Jul 07, 2012 at 10:23:00PM +0200, Bastian Blank wrote: All the informations recorded by default are available for normal users or at most need CAP_DAC_READSEARCH. I thought about it and no plugin should need this permission ever. All this stuff should be done by group permissions. I suggest to do the following: run collectd as nobody (or a newly created user 'collectd') by default; make that user configurable through /etc/default/collectd This works with start-stop-daemon. I have one test system run this way. make it possible to provide a list of capabilities (through /etc/default/collectd) that would be applied to the collectd binary in the init script. This does not work without code modifications. Capabilities in the effective and permitted set do not survive execve(2) if not set in the filesystem. What collectd should do IMHO: - General capability support: - Capabilities not known safe are dropped immediately even if run by root. It never needs to modify network setup or mount stuff. Yes, this may break setups if stuff is not root-owned. - Plugins can specify what capabilities they need, they will be retained, all others dropped. - Support to set user: - The process needs to set SECBIT_KEEP_CAPS to retain capabilities while changing user from root. - Maybe set security bit SECBIT_NOROOT. It removes capabilities from all suid-root processes it may try to call. Bastian -- Killing is wrong. -- Losira, That Which Survives, stardate unknown -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680660: collectd - runs as root without apparent reason
Hi, (Cc'ing the collectd mailing list, hoping for further input and suggestions. For a full log of this bug report, see http://bugs.debian.org/680660.) On Mon, Jul 16, 2012 at 03:19:37PM +0200, Bastian Blank wrote: On Sun, Jul 08, 2012 at 02:50:02PM +0200, Sebastian Harl wrote: On Sat, Jul 07, 2012 at 10:23:00PM +0200, Bastian Blank wrote: All the informations recorded by default are available for normal users or at most need CAP_DAC_READSEARCH. I thought about it and no plugin should need this permission ever. All this stuff should be done by group permissions. There might be plugins requiring some such permission in order to read information from /proc/ but I haven't double-checked that. I suppose that would be very few exceptions, though. I suggest to do the following: run collectd as nobody (or a newly created user 'collectd') by default; make that user configurable through /etc/default/collectd This works with start-stop-daemon. I have one test system run this way. Yep, that's how I was going to implement that. make it possible to provide a list of capabilities (through /etc/default/collectd) that would be applied to the collectd binary in the init script. This does not work without code modifications. Capabilities in the effective and permitted set do not survive execve(2) if not set in the filesystem. Well, I was going to place them in the file-system (if possible). That would have been a first step in the right direction which would not require modifications to collectd and would be easy to modify for testing purposes. Not sure which filesystems support capabilities, though. What collectd should do IMHO: - General capability support: - Capabilities not known safe are dropped immediately even if run by root. It never needs to modify network setup or mount stuff. Yes, this may break setups if stuff is not root-owned. - Plugins can specify what capabilities they need, they will be retained, all others dropped. Sounds good to me. This could be implemented by providing a new callback like 'plugin_register_capability'. - Support to set user: - The process needs to set SECBIT_KEEP_CAPS to retain capabilities while changing user from root. Sounds good to me. - Maybe set security bit SECBIT_NOROOT. It removes capabilities from all suid-root processes it may try to call. This would be in the spirit of the exec plugin which refuses to run any external programs / scripts as root. However, I'm not entirely sure if that's a good idea, though, as that just limits the possibilities of the user while I don't see much security benefits. Cheers, Sebastian -- Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin signature.asc Description: Digital signature
Bug#680660: [collectd] Bug#680660: collectd - runs as root without apparent reason
Hi, - Maybe set security bit SECBIT_NOROOT. It removes capabilities from all suid-root processes it may try to call. This would be in the spirit of the exec plugin which refuses to run any external programs / scripts as root. However, I'm not entirely sure if that's a good idea, though, as that just limits the possibilities of the user while I don't see much security benefits. Cheers, Many times I had to write silly wrappers/crons just because some stat data had to be obtained as root user. What would be nice is a ability to specify enabled capabilities per exec while allowing to run them on user root (possibly with IKnowThatIsUnsafe switch ;) ) -- Mariusz Gronczewski -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680660: collectd - runs as root without apparent reason
Hi, On Sat, Jul 07, 2012 at 10:23:00PM +0200, Bastian Blank wrote: All the informations recorded by default are available for normal users or at most need CAP_DAC_READSEARCH. There is no reason to run collectd with the highest permissions on the system. Agreed. Another (I suppose) commonly required capability is CAP_NET_RAW (required by the ping plugin. I suggest to do the following: run collectd as nobody (or a newly created user 'collectd') by default; make that user configurable through /etc/default/collectd and make it possible to provide a list of capabilities (through /etc/default/collectd) that would be applied to the collectd binary in the init script. Does that sound sane to you? Cheers, Sebastian -- Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin signature.asc Description: Digital signature
Bug#680660: collectd - runs as root without apparent reason
Source: collectd Version: 5.1.0-2 Severity: important All the informations recorded by default are available for normal users or at most need CAP_DAC_READSEARCH. There is no reason to run collectd with the highest permissions on the system. Bastian -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.4-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
