| Summary: | sys-apps/portage: quickpkg leaks information | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Finn Thain <fthain> |
| Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | security |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=890823 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 181949 | ||
| Attachments: | set default umask to 0077 and allow QUICKPKG_DEFAULT_OPTS to override | ||
|
Description
Finn Thain
2007-06-18 07:09:13 UTC
I agree leaking /etc/shadow is bad. But i can't reproduce what you're claiming with baselayout. [sleipnir:/usr/portage/packages/All] tar tvjf baselayout-1.12.9-r2.tbz2|grep '\./etc/[^/]\+$' -rw-r--r-- root/root 34 2007-06-18 10:34 ./etc/gentoo-release -rw-r----- root/root 1494 2007-06-18 10:34 ./etc/sysctl.conf -rw-r--r-- root/root 108 2007-06-18 10:34 ./etc/shells -rw-r--r-- root/root 35842 2007-06-18 10:34 ./etc/services -rw-r--r-- root/root 1641 2007-06-18 10:34 ./etc/rc.conf -rw-r--r-- root/root 1623 2007-06-18 10:34 ./etc/protocols -rw-r--r-- root/root 2141 2007-06-18 10:34 ./etc/profile -rw-r--r-- root/root 196 2007-06-18 10:34 ./etc/networks -rw-r--r-- root/root 701 2007-06-18 10:34 ./etc/issue.logo -rw-r--r-- root/root 30 2007-06-18 10:34 ./etc/issue -rw-r--r-- root/root 1658 2007-06-18 10:34 ./etc/inputrc -rw-r--r-- root/root 399 2007-06-18 10:34 ./etc/filesystems bzip2: (stdin): trailing garbage after EOF ignored BTW 600 may break some rsync scripts which take advantage of the binary packages feature, 640 portage:portage or root:portage should be preferred. Have you found a real information leakage? If not, i would close it as Invalid. Oh, and don't play with the severity with too much coffee. The umask should not matter since quickpkg is supposed to put the files directly into the tar archive with the existing permissions. Permissions should not change in any way. Raphael: I can't reproduce it either. I mentioned shadow because I had a tbz2 that contained it (or so I thought, but I removed it and now I can't double check). In the listing you posted, /etc/sysctl.conf is leaked instead. Of course, the nature of the leak will depend on which package you try it on. 640 root:portage isn't a safe default. If 600 "might break" scripts, then break them. How can you confidently presume that the portage group is empty? Perhaps you could change quickpkg to allow it to set the group to portage and mode bits to 640 if run as root and a new option is passed. As to severity, running quickpkg as root really is a major feature if you maintain production servers. It provides a back-out plan for upgrades, and it has saved me before (and yes, I use test boxes too). But I don't care too much whether others appreciate quickpkg or not. As a workaround, I changed the perms on /usr/portage/packages to 700, but I suspect that there are temporary files involved that aren't protected by that workaround. Zac: what existing permissions? The problem relates to the new tbz2 file, not the source files. As to umask, tightening the umask may not fix the bug unless it covers temporary files are created by quickpkg or tar as well. PS. umask would be 077, so the mode bits go to 600. The bug report wasn't clear on that. And no I don't know what "tgbz" is either. Yes, coffee would help... while you might be able to make an argument about the default perms on the tbz2s, but /etc/shadow is not leaked anywhere regardless we specifically do not have baselayout record it in CONTENTS so that when a tarball is made, it is not added ... same goes for groups and passwd and ... /etc/sysctl.conf is hardly a leaky file (In reply to comment #3) > As a workaround, I changed the perms > on /usr/portage/packages to 700, but I suspect that there are temporary files > involved that aren't protected by that workaround. The temporary file is kept inside $PKGDIR, so your workaround completely protects it. The 022 umask in quickpkg was added for bug #143340 so that users without superuser privileges could do --pretend commands with binary packages. We can add an environment variable to control that if necessary. I've never noticed any sensitive information being stored in packages, so the idea of restricting read privileges there never occurred to me. Created attachment 122450 [details, diff]
set default umask to 0077 and allow QUICKPKG_DEFAULT_OPTS to override
This patch applies against portage-2.1.3_rc4.
Zac: Thanks for the patch. Mike: sysctl.conf is a leak. $ sysctl -a ... error: permission denied on key 'kernel.cap-bound' And yes, I used to set kernel.cap-bound in that file (though these days I patch the kernel instead). Simply grepping the tree for chmod indicates that there are other files installed without world-read perms. Besides which, you can't claim a file isn't leaky without knowing what it is in it. Once quickpkg makes it world readable, _then_ you can look at and tell me I didn't leak anything. ;-) what i meant is the contents of sysctl.conf are rarely (ever?) an issue if made world readable, unlike the shadow file That's what I thought you meant. By implication you are also saying that /proc/sys/kernel/cap-bound would be equally secure if it were 644 rather than 600. I can't really argue that point. I presume that there is a reason that the kernel makes it 600 and not 644, but I don't really know for sure. That debate is off-topic anyway, since the bug isn't confined to baselayout (e.g. net-nds/openldap has to deny read to /etc/openldap/slapd.conf to protect the rootdn password). it isnt really off topic ... this bug is assigned to the security team which means once the issue is solved in portage, they need to determine whether to issue a glsa unless there is a true risk here (which i dont think sysctl.conf qualifies for), then there's no need for a glsa any package that may have passwords in them should not be listed in CONTENTS ... i think i should get this spelled out in our docs in the meantime, i think you should file a sep bug report against openldap > unless there is a true risk here (which i dont think sysctl.conf qualifies > for), then there's no need for a glsa I don't understand. Why is cap-bounds not sensitive? Upstream seems to think it is. And even if it is not sensitive, surely there ought to be a glsa against portage anyway? > any package that may have passwords in them should not be listed in CONTENTS > ... i think i should get this spelled out in our docs I don't understand. How is that relevant to this bug (against portage) unless the criterion is file permissions, rather than file contents (passwords)? > in the meantime, i think you should file a sep bug report against openldap Shouldn't I file a bug against baselayout also? Is this bug (against portage) really invalid? Look, I'm happy to file more bugs, but what are the bugs exactly? Why should I be asking for more stuff stripped from CONTENTS? I actually _like_ being able to do "equery belongs /etc/foo"... because users will blindly distribute packages without realizing they've packaged up sensitive information as i mentioned, baselayout is not affected because the sensitive files are not listed in CONTENTS i think the proposed patch here for quickpkg plus the comments on gentoo-dev wrt CONFIG_PROTECT+quickpkg (which i'll handle) are the way to go I think so, too. (In reply to comment #13) > i think the proposed patch here for quickpkg plus the comments on gentoo-dev > wrt CONFIG_PROTECT+quickpkg (which i'll handle) are the way to go Hmm, how about checking the md5sum and only skip the files if they were modified? Or are there any potential leaks with vanilla config files? (In reply to comment #15) > Hmm, how about checking the md5sum and only skip the files if they were > modified? Or are there any potential leaks with vanilla config files? If the quicpkg with --include-config=y is used to create a package and that package is then merged onto a system, the merge process will recalculate the md5sum for every file. After that, even files containing sensitive data could have their md5 recorded in the contents. In portage-2.1.3_rc5, quickpkg supports --include-config and --include-unmodified-config options. Both options are disabled by default. Set QUICKPKG_DEFAULT_OPTS in make.conf if you want to change the default options. Re-assigning to portage-team (In reply to comment #17) > Re-assigning to portage-team So you don't consider this to be a security issue? |
