Bugzilla Bug 113474

Well, the problem is similar to bug 103878 and the topic discussed at this
thread
http://groups.google.com/group/linux.gentoo.dev/browse_frm/thread/bf1b1d88664748b1/d2ce50dcd67cca65

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

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.