[collectd] Bug#680660: collectd - runs as root without apparent reason
tokkee at debian.org
Mon Jul 16 15:44:10 CEST 2012
(Cc'ing the collectd mailing list, hoping for further input and
suggestions. For a full log of this bug report, see
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
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,
> 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
> - 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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Digital signature
More information about the collectd