[collectd] Bug#680660: collectd - runs as root without apparent reason

[Sebastian Harl]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mailman.verplant.org/pipermail/collectd/attachments/20120716/1d967d6a/attachment.pgp>