Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 113474 - linux-info pulls in virtual/linux-sources when it's unwanted (was: gnupg build failure)
Summary: linux-info pulls in virtual/linux-sources when it's unwanted (was: gnupg buil...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Crypto team [DISABLED]
Depends on:
Blocks: 125690 136665
  Show dependency tree
Reported: 2005-11-24 08:29 UTC by Georgi Georgiev
Modified: 2006-09-30 14:06 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Georgi Georgiev 2005-11-24 08:29:37 UTC
Well, the problem is similar to bug 103878 and the topic discussed at this

gnupg should not abort at the "kernel_is lt 2 6 9" check since it *does not*
require the kernel sources to build properly.

Steps to reproduce:

1. emerge -C virtual/linux-sources
2. emerge gnupg
3(actual). watch it die
3(expected). flawless emerge
Comment 1 Chris Gianelloni (RETIRED) gentoo-dev 2005-11-24 08:47:26 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.
Comment 2 Daniel Black (RETIRED) gentoo-dev 2005-11-24 13:01:26 UTC
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. 
Comment 3 Jason S. 2005-11-24 14:58:24 UTC
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
Comment 4 Georgi Georgiev 2005-11-24 17:31:47 UTC
(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.
Comment 5 Daniel Black (RETIRED) gentoo-dev 2005-11-24 23:28:45 UTC
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. 
Comment 6 Daniel Black (RETIRED) gentoo-dev 2005-11-25 00:18:35 UTC
fixed due to current stabilisation request (bug 113289). Suggestions will be  
noted for next revisions.  
Comment 7 Harald van Dijk (RETIRED) gentoo-dev 2005-11-25 15:12:52 UTC
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?
Comment 8 Georgi Georgiev 2006-02-15 16:04:57 UTC
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?
Comment 9 Emanuele Giaquinta (RETIRED) gentoo-dev 2006-02-17 02:00:11 UTC
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?
Comment 10 Chris Gianelloni (RETIRED) gentoo-dev 2006-02-17 06:13:54 UTC
"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).
Comment 11 Emanuele Giaquinta (RETIRED) gentoo-dev 2006-02-17 06:42:18 UTC
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.
Comment 12 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-02-17 06:44:12 UTC
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..
Comment 13 Alex Tomkins 2006-02-21 06:10:33 UTC
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-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"
                 " for more information\n"));

The FAQ <> 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.
Comment 14 Gerard Neil 2006-06-03 07:01:38 UTC
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...
Comment 15 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2006-06-27 20:59:21 UTC
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.
Comment 16 SpanKY gentoo-dev 2006-06-27 22:36:03 UTC
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 ?
Comment 17 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2006-06-27 23:23:34 UTC
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.
Comment 18 SpanKY gentoo-dev 2006-06-28 18:18:28 UTC
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
Comment 19 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2006-06-28 19:04:17 UTC
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.
Comment 20 SpanKY gentoo-dev 2006-06-29 15:50:58 UTC
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
Comment 21 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2006-06-29 15:52:52 UTC
crypto herd: any other opinions, or are we in agreement with dropping the setuid bit? please post +1/-1.
Comment 22 Daniel Black (RETIRED) gentoo-dev 2006-06-29 16:31:28 UTC
+1 - Thanks Robin
Comment 23 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2006-06-29 16:53:32 UTC
Could I get one more crypto opinion please?
Comment 24 Daniel Black (RETIRED) gentoo-dev 2006-07-01 05:38:52 UTC
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.
Comment 25 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2006-09-30 13:59:49 UTC
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.
Comment 26 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2006-09-30 14:06:22 UTC
fixed in 1.4.5-r1 now.
once it goes stable, the old versions can be removed, and then this problem disappears forever.