From: "Namsun Ch'o" <namnamc@Safe-mail.net>
To: eduardo.otubo@profitbricks.com
Cc: armbru@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Add syscalls for -runas and -chroot tothe seccomp sandbox
Date: Sun, 4 Oct 2015 01:05:10 -0400 [thread overview]
Message-ID: <N1-r-GeFrJj6n@Safe-mail.net> (raw)
> Our intention since the beginning was to protect the host from the
> illegal guest operations. But you do have an interesting point about
> flaws on qemu itself. Perhaps this might be something I could work on to
> improve (start a bigger whitelist and get it tighter before guest
> launches).
The seccomp filters are always passed on through execve(), so it would not be
possible to have the parent have chroot() whitelisted to chroot, then spawn a
child without it. As far as I know, even a root process cannot chroot another
process, even its child, so if the process is to chroot at all, it must have
the chroot syscall whitelisted. What can be done, however, is using the
argument passed to -chroot as the filter. The same could be done with setuid,
by having it only whitelist the uid which is given at -runas.
An example, using chdir (I presume QEMU uses chdir(dir) then chroot(".")):
sh# mkdir /tmp/chroot
sh# cat | gcc -lseccomp -x c -
#include <stdio.h>
#include <fcntl.h>
#include <seccomp.h>
void main(void)
{
const char *dir = "/tmp/chroot";
scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_TRAP);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(mkdir), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(fchdir), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(open), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(chdir), 1,
SCMP_A0(SCMP_CMP_EQ, dir));
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(chroot), 1,
SCMP_A0(SCMP_CMP_EQ, "."));
seccomp_load(ctx);
chdir(dir);
chroot(".");
/* evil code starts here */
const int fd = open(".", O_DIRECTORY);
mkdir("foo");
chroot("foo");
fchdir(fd);
chdir("..");
chdir("..");
chdir("..");
chroot(".");
}^D^D
sh# strace -qq -e open,mkdir,chdir,chroot ./a.out 2>&1 | fold -s -w 80
chdir("/tmp/chroot") = 0
chroot(".") = 0
open(".", O_RDONLY|O_DIRECTORY) = 3
mkdir("foo", 0200000) = 0
--- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x34400a7d397,
si_syscall=161, si_arch=3221225534} ---
+++ killed by SIGSYS +++
Bad system call
sh# grep 161 /usr/include/asm/unistd_64.h
#define __NR_chroot 161
So there's really no need to disable chroot() or setuid(), just filter the
arguments based on command line input to make them impossible to abuse.
next reply other threads:[~2015-10-04 5:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-04 5:05 Namsun Ch'o [this message]
2015-10-05 5:23 ` [Qemu-devel] [PATCH] Add syscalls for -runas and -chroot tothe seccomp sandbox Markus Armbruster
-- strict thread matches above, loose matches on Subject: below --
2015-10-05 22:58 Namsun Ch'o
2015-10-06 5:36 ` Markus Armbruster
2015-10-04 4:00 Namsun Ch'o
2015-10-05 5:20 ` Markus Armbruster
2015-10-05 8:22 ` Daniel P. Berrange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=N1-r-GeFrJj6n@Safe-mail.net \
--to=namnamc@safe-mail.net \
--cc=armbru@redhat.com \
--cc=eduardo.otubo@profitbricks.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).