Bug 477102 – <net-misc/iodine-0.7.0-r1: Insecure file permissions on /etc/conf.d/iodined

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Christian Hoffmann 2013-07-16 19:18:22 UTC]

=net-misc/iodine-0.6.0_rc1-r1 installs /etc/conf.d/iodined with root:root 644 permissions. As one is usually supposed to configure a password there, I would consider this file being world-readable a problem.

I have changed permissions to root:nogroup 640 and iodined still seems to work properly.

On a side-note, it may be preferable if iodine ran with its own permissions rather than nobody/nogroup, because isolation against other nobody/nogroup processes would not be guaranteed otherwise, IMO. But I would rather classify this part as hardening instead of an actual problem.

I only tested 0.6.0_rc1-r1, but I guess other versions are affected as well.

[Comment 1 Aaron Bauman (RETIRED) 2016-11-20 12:18:14 UTC]

@maintainer(s), could you please adjust the permissions appropriately for the configuration file post install?  It does contain passwords that are world readable.

[Comment 2 Aaron Bauman (RETIRED) 2016-11-25 12:50:25 UTC]

Bumped with hardened configuration file permissions:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=508426be9fae3be1f70cfb9e642b40d2e258a040

Cleanup:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=82d62d66c8eef722a36e6136398521d92d07c644

[Comment 3 Jason A. Donenfeld 2016-11-25 14:11:44 UTC]

This was thoughtlessly analyzed. The solution committed is not adequate.

/etc/conf.d/iodined may be chmodded to 600. It does not to be owned by nogroup, since it is parsed by /etc/init.d/iodined as root. After /etc/init.d/iodined reads /etc/conf.d/iodined, the invoked /usr/sbin/iodined drops privileges.

I'll fix things and commit it to the tree.