Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 498676 - app-arch/tar requires mknod to extract xattrs
Summary: app-arch/tar requires mknod to extract xattrs
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-20 11:44 UTC by ViliusSutkus89
Modified: 2014-01-24 16:24 UTC (History)
4 users (show)

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


Attachments
qmerge log (file_498676.txt,797 bytes, text/plain)
2014-01-20 11:45 UTC, ViliusSutkus89
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ViliusSutkus89 2014-01-20 11:44:46 UTC
During install phase llvm tries to mknod to create these files:
/usr/bin/lli
/usr/bin/llvm-rtdyld

Steps to reproduce:
1. Config kernel with CONFIG_GRKERNSEC_CHROOT_MKNOD=y
2. Chroot into gentoo system
3. emerge --usepkg llvm
4. See messages in dmesg about denied mknod of said 2 files.
5. Install doesn't stop immediatelly.
6. Fail hard (fail message attached)

Affected versions:
sys-devel/llvm-3.4
sys-devel/llvm-3.3-r3
Can neither deny nor confirm earlier versions.

Will try to reproduce without using BINPNG.
Comment 1 ViliusSutkus89 2014-01-20 11:45:31 UTC
Created attachment 368234 [details]
qmerge log
Comment 2 ViliusSutkus89 2014-01-20 15:39:07 UTC
Compile from source in chroot succeeds nicely, only BINPKG install is affected.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-01-21 17:12:51 UTC
Looks like some Hardened black magic to me.
Comment 4 Attila Tóth 2014-01-22 20:50:18 UTC
I suspect this is a feature of the kernel option you've mentioned.
I suggest toggling the option through setting /proc/sys/kernel/grsecurity/chroot_deny_mknod to 0 temporarily for building this package. Unless you've sealed the kernel and you can no longer disable it temporarily.
Comment 5 ViliusSutkus89 2014-01-23 16:32:22 UTC
I think I was a bit misunderstood.

What I'm trying to find out is, why is there a need to mknod ( create stuff like /dev/... ) while extracting a BINPKG ? It's not like these two mentioned files are a result of mkdnod themselves, they are just plain binary executables.
Comment 6 ViliusSutkus89 2014-01-23 21:44:55 UTC
4. See messages in dmesg about denied mknod of said 2 files.

These are the exact dmesg messages:

[ 6307.996509] grsec: denied mknod of /tmp/llvm_chroot/var/tmp/portage/sys-devel/llvm-3.4/image/usr/bin/lli from chroot by /tmp/llvm_chroot/bin/tar[tar:16012] uid/euid:0/0 gid/egid:0/0, parent /tmp/llvm_chroot/bin/bash[bash:16010] uid/euid:0/0 gid/egid:0/0
[ 6308.103995] grsec: denied mknod of /tmp/llvm_chroot/var/tmp/portage/sys-devel/llvm-3.4/image/usr/bin/llvm-rtdyld from chroot by /tmp/llvm_chroot/bin/tar[tar:16012] uid/euid:0/0 gid/egid:0/0, parent /tmp/llvm_chroot/bin/bash[bash:16010] uid/euid:0/0 gid/egid:0/0


also, the attachment name says "qmerge", that's a typo. Should be emerge.
Comment 7 ViliusSutkus89 2014-01-23 22:58:22 UTC
So I narrowed the problem down to "tar requires mknod to process xattrs"

Can reproduce with:
touch empty_file
paxctl-ng -E empty_file
tar c empty_file --xattrs | tar x --xattrs
Comment 8 ViliusSutkus89 2014-01-24 00:12:26 UTC
app-arch/tar extract.c

static int
set_xattr (char const *file_name, struct tar_stat_info const *st,
           mode_t invert_permissions, char typeflag, int *file_created)
{
  int status = 0;

#ifdef HAVE_XATTRS
  bool interdir_made = false;

  if ((xattrs_option > 0) && st->xattr_map_size)
    {
      mode_t mode = current_stat_info.stat.st_mode & MODE_RWX & ~ current_umask;

      do
        status = mknodat (chdir_fd, file_name, mode ^ invert_permissions, 0);
      while (status && maybe_recoverable ((char *)file_name, false,
                                          &interdir_made));

      xattrs_xattrs_set (st, file_name, typeflag, 0);
      *file_created = 1;
    }
#endif

  return(status);
}


mknodat function call has 0 as dev_t parameter, am I correct to assume that this code uses mknodat as atomic "touch; chmod" ?
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-01-24 04:43:22 UTC
Assigning to base-system@ since they maintain app-arch/tar, and CC-ing dev-portage@ to let them know of the binpackage problem.
Comment 10 Anthony Basile gentoo-dev 2014-01-24 12:54:01 UTC
(In reply to palme3000 from comment #5)
> I think I was a bit misunderstood.
> 
> What I'm trying to find out is, why is there a need to mknod ( create stuff
> like /dev/... ) while extracting a BINPKG ? It's not like these two
> mentioned files are a result of mkdnod themselves, they are just plain
> binary executables.

I'd like to know if it works if you do

 echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mknod

to confirm your suspicions about that code in tar failing.  I'm like 99% convinced given your detective work.

(In reply to palme3000 from comment #8)
> app-arch/tar extract.c
> [...]
> mknodat function call has 0 as dev_t parameter, am I correct to assume that
> this code uses mknodat as atomic "touch; chmod" ?

It seems that way, although why it needs to be atomic, I'm not sure.  I'm not sure what might race there.  But a simple strace shows that it is indeed atomic.  Maybe it doesn't need to be, but its just a faster way of doing touch; chmod.

Having said that, building in a chroot on a hardened systems is going to hit stuff like this.  You can't have it both ways: you can't hardened your chroot against escape (eg creacte a block device for / outside the root, mount it, and you're out), and the use it to mknod.  I recommend that you do:

  for i in /proc/sys/kernel/grsecurity/chroot_* ; do echo 0 > $i ; done

before you build and then restore after.  I know you're opening up a bunch of wholes, but, as I said, you can't have it both ways.
Comment 11 ViliusSutkus89 2014-01-24 16:24:38 UTC
Just tried with CONFIG_GRKERNSEC_CHROOT_MKNOD=n and everything seems to work fine... can untar archives with xattr's in chroot ... as expected.

Will wait for tar people to say something before marking as wontfix.