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
