The pkg_config phase for munin calls "chown -R" on a directory: pkg_config() { ... chown -R munin:munin /var/lib/munin/.ssh || die If this phase is run more than once (ever), the munin user can exploit this to gain root. If he places a hard link to a root-owned file under /var/lib/munin/.ssh, then the next call to "chown -R" will give ownership of root's file to the "munin" user. For example, 1. emerge --config munin 2. su -s /bin/sh -c 'ln /etc/passwd /var/lib/munin/.ssh/x' munin 3. emerge --config munin 4. /etc/passwd is owned by "munin"
This bug shows that it is under embargo, but there is no deadline. Please advice on how or when to proceed. We know the specific files we create here, so we can use this instead: chown munin:munin /var/lib/munin/.ssh/id_{rsa,ecdsa}{,.pub}
(In reply to Hans de Graaff from comment #1) > This bug shows that it is under embargo, but there is no deadline. Please > advice on how or when to proceed. > > > We know the specific files we create here, so we can use this instead: > > chown munin:munin /var/lib/munin/.ssh/id_{rsa,ecdsa}{,.pub} That "chown" will still follow a symlink, so it's important that every directory involved be owned (and writable only) by root. Is that the case even though /var/lib/munin is the "munin" user's home directory (I haven't checked)? enewuser munin 177 -1 /var/lib/munin munin If it will work, I would suggest instead using "su -s /bin/sh -c ... munin" to perform the key generation *as the munin user* so that you don't have to try to fix things afterwards.
(In reply to Hans de Graaff from comment #1) > This bug shows that it is under embargo, but there is no deadline. Please > advice on how or when to proceed. Oh, and there's nothing special about the "embargo" status, I was just asked to keep these sorts of issues private until a fix is available.
Another thing to consider is that everyone who ran "emerge --config munin" up until now will still have "munin" owning /var/lib/munin and everything under it. Fixing that is itself a hairy proposition, so if you can use "su" to eliminate the chowns, that's one less thing to think about.
Unrestricting and reassigning to security@ per bug #705894
unrestricting per bug 705894
Maintainers/mjo, is this now obsolete with the new user/group functionality?
No, nothing has changed. (It would also be nice if acct-user/munin followed the devmanual's guidelines for its home directory. Right now the package and the user are pointlessly and dangerously coupled.)