| Summary: | app-arch/tar requires mknod to extract xattrs | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | ViliusSutkus89 |
| Component: | [OLD] Development | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | dev-portage, hardened, mgorny, voyageur |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | qmerge log | ||
|
Description
ViliusSutkus89
2014-01-20 11:44:46 UTC
Created attachment 368234 [details]
qmerge log
Compile from source in chroot succeeds nicely, only BINPKG install is affected. Looks like some Hardened black magic to me. 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. 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. 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. 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 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" ?
Assigning to base-system@ since they maintain app-arch/tar, and CC-ing dev-portage@ to let them know of the binpackage problem. (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. 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. feel free to start a discussion on upstream lists, but this doesn't sound problematic to me https://lists.gnu.org/mailman/listinfo/help-tar |
