| Summary: | linux-info pulls in virtual/linux-sources when it's unwanted (was: gnupg build failure) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Georgi Georgiev <chutz+bugs.gentoo.org> |
| Component: | Current packages | Assignee: | Crypto team [DISABLED] <crypto+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | alt, ed, exg, kernel, kfm, rockoo, tomkins, vapier, vxjasonxv, wolf31o2, xyzzy |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 125690, 136665 | ||
|
Description
Georgi Georgiev
2005-11-24 08:29:37 UTC
I just ran across this in tinderbox testing. While this isn't something that is 100% fatal, I can see issues where gnupg might be pulled into an installation before the kernel is configured. option one check if [ -n "${KV_DIR}" ] before kernel_is
option two call get_running_version() before kernel_is and make the assumption
that the current version is it.
This bug is affecting myself (running in a vserver environment) because there's no kernel sources to link against, nor a /usr/src/linux at all. I have 1.4.1 installed, but can't get up to 1.4.2-r2 (In reply to comment #2) > option one check if [ -n "${KV_DIR}" ] before kernel_is > > option two call get_running_version() before kernel_is and make the assumption > that the current version is it. Making any kinds of checks is insanely wrong. All I have to do is reboot in another kernel and the results of those checks will be void. yes there is no perfect solution. The checks aim to only install gpg suid in cases where it is required it lock kernel memory associated with keys. I can either option if the kernel cannot be determined: option one - install suid option two - don't install suid. I don't see major disadvantages with either. Offer your preference and I'll implement it. Please don't just say i'm wrong and don't offer a solution cause I'm sure the next person will do the same. I agree it shouldn't break when there is no kernel configured. fixed due to current stabilisation request (bug 113289). Suggestions will be noted for next revisions. My suggestion: only if the running kernel and the kernel sources are both detected and are both >=linux-2.6.9, don't install suid. Otherwise -- if either is not detected, or if either is <linux-2.6.9 -- do install suid. If I'm understanding right, the idea is that suid is necessary for security with older versions of Linux, and suid install doesn't actually cause problems with newer versions of Linux, so installing suid when not certain would be playing it safe. Does that make sense? One more time we're back where we started. This time gnupg wants virtual/linux-sources instead of aborting, though. Why? This is completely unnecessary for the reasons stated in this bug already. It seems that fixing bug 120233 caused the problem this time. Anyway, could you guys work out a way to not pull in the kernel source unless absolutely necessary? I've made the virtual-linux/sources dep in linux-info.eclass, with the agreement of johnm, conditional to the USE_EXPAND variable kernel_linux. Can't we do the same with the calls to get_running_version and kernel_is until they become more portable? "gnupg should not abort at the "kernel_is lt 2 6 9" check since it *does not* require the kernel sources to build properly." It shouldn't depend on any sources for any reason. It does not require them to build. Daniel mentioned why the echeck was in place, and it was a valid reason. However, it doesn't mean that sources are required to build/install. Remember that the check is in pkg_setup, meaning it does the check even on binary installs, even though the change is done in src_install (meaning it is a worthless check on binary packages). The change is currently done in src_install and pkg_postinst, being the latter the correct place to do it; while it does not harm, the one in src_install is redundant. CCing alt and reopening as the discussion is still in place, i'd say.. I think the first thing to say it's that the eclass is right as it is, the checks there are right as they are. The problem is that checking for specific kernel when building a package that does not really interact with the kernel itself is as evil as using uname in a configure.. I'm currently running Gentoo in a Xen virtual server, the current behavior of linux-info is asking me to download gentoo-sources, similar to Jason in comment #3: [ebuild N ] sys-kernel/gentoo-sources-2.6.15-r1 -build -doc -symlink (-ultra1) 39,086 kB [ebuild U ] app-crypt/gnupg-1.4.2.1 [1.4.2-r3] -X +bzip2 -caps +curl -ecc -idea -ldap +nls +readline (-selinux) -smartcard -static -usb +zlib 0 kB After looking through the gnupg source, it comes up with: log_info(_("WARNING: using insecure memory!\n")); log_info(_("please see http://www.gnupg.org/faq.html" " for more information\n")); The FAQ <http://www.gnupg.org/documentation/faqs.html#q6.1> gives instructions on setting gnupg suid, which should be enough for most users. My opinion is that the ebuild should *warn* people if they're running anything older than 2.6.9, it should not be installed suid under any kernel version. If for some strange reason the user switches to a kernel which can't support secmem without suid then gnupg will warn them anyway. It should not use linux-info.eclass, this is forcing gnupg to depend on virtual/linux-sources. I agree with comment #12 and #13. Having an install or compile-time dependency on kernel sources is just asking for trouble. It involves assumptions which are bound to be broken in the future. It means that a large package can be pulled in purely for the purposes of making these dud assumptions. Worst of all, it encourages ebuild developers to assume that this sort of dependency is ok without thinking it through, which can only lead to more dependencies and more trouble. This is a runtime problem. Why not give it a runtime solution and empower the user? 1. Allow the install to be controlled via USE=suid 2. Add a little something to the gentoo gnupg guide about the issue. 3. Patch the gnupg runtime warning mentioned in comment #13 to be more helpful for gentoo... give it a link to the doco in 2 as well as to the FAQ. Or even just a message that USE=suid is available. 3. Don't install suid by default for any version. 4. Have a warning in the ebuild. It doesn't need to check the running kernel version, just warn. If this doesn't satisy people then maybe forcing the user to make the decision would: fail the build unless one of USE=suid or USE=nosuid is present... Ok, i'm trying to follow up on this now. On the gnupg side, there's a specific bit of behavior we are after: - If the kernel is older than 2.6.9, setuid is needed for secure operation. - If the kernel is newer than 2.6.9, setuid is no longer needed, and in fact is undesirable for gnupg. USE=suid is not acceptable for this reason. This is the only dependancy we presently have on the kernel (it used to be more, but I double checked, and upstream has cleaned up that stuff). To obtain the information of which kernel is running, we use get_running_version from linux-info.eclass, and then 'kernel_is lt 2 6 9' also from linux-info. Unfortuntely linux-info.eclass also has this line: DEPEND="kernel_linux? ( virtual/linux-sources )" So although the ebuild doesn't care about kernel sources, the linux-info.eclass does! I think it really shouldn't. Either that or seperate the functionality in it that needs kernel sources from the functionality that doesn't. is the setuid handling done properly at runtime ? in other words, say i emerge gnupg with 2.6.8 so it gets +s ... when i upgrade to 2.6.16, can i safely drop the setuid bit and gnupg will continue to work properly ? Spanky: it's complicated. In the configure script, gnupg checks if the mlock operation works correctly on your system (see the test named GNUPG_CHECK_MLOCK). The test specifically will pass if you have CAP_IPC_LOCK capability for the pages being tested. Prior to 2.6.9, this means you have to be root, or have the capability flag in some other way. After 2.6.9, the kernel allows CAP_IPC_LOCK to the owner of the page, which relaxes the requirement of setuid root. So you compile on 2.6.8, mlock fails unless root. Thus the tests selects the setuid codepath, which setuid(0) before the mlock, and drops privileges afterwards (or it's supposed to, but this isn't entirely trusted by all parties). In theory it works ok on 2.6.9+ at this point. Still vulnerable if there is a code injection that uses setuid before the privelege dropping takes place. If you chmod u-s on the binary at this point, it should work fine, without secure issues. If you compile on 2.6.9+, mlock works, and the setuid codepath is not compiled into the code. Setting the setuid bit in this case leaves getuid=X,geteuid=0, and the code injection problem again. For kernels prior to 2.6.9, incl the 2.4 series, using linux capabilities is one possible option, but still not foolproof, and it's broken in GnuPG anyway presently. so gnupg sucks ... if you compile the package on >=2.6.9 and then run it on <=2.6.8, it'll fail right ? seems to me like the mlock() test should be at runtime: - mlock() works - spit a warning if setuid - continue about your business - mlock() fails - abort if not setuid - continue about your business if setuid vapier: yes. however by 'fail' the existing behavior is to spit out a warning about insecure memory with the point to the upstream FAQ. setuid is undesirable because of it's other security implications when holes are found in gnupg. How about this for behavior: We just tell users to use something newer than 2.6.8, and don't install it setuid at all. ok, so if it'll still run on <=2.6.8 in non-setuid mode but just spit a warning about insecure memory usage, just dropping the setuid bit for everyone seems acceptable to me crypto herd: any other opinions, or are we in agreement with dropping the setuid bit? please post +1/-1. +1 - Thanks Robin Could I get one more crypto opinion please? whatever is chosen the same applies to the suid of pinentry. another crypt person is wanted for Robin's vote here. Comment here and be counted in the vote. I'm going to take the lack of further votes on the setuid removal to be positive, and go ahead with it, so that linux-info is no longer needed. fixed in 1.4.5-r1 now. once it goes stable, the old versions can be removed, and then this problem disappears forever. |
