[Qemu-devel] seccomp blacklist is not applied to all threads

2018-08-13 Thread Jann Horn via Qemu-devel
Hi!

I have noticed that when a QEMU build from git master is started with
"-seccomp on", the seccomp policy is only applied to the main thread,
the vcpu worker thread and the VNC thread (I'm using VNC in my
config); the seccomp policy is not applied to e.g. the RCU thread
because it is created before the seccomp policy is applied and
SECCOMP_FILTER_FLAG_TSYNC isn't used. In practice, this makes the
seccomp policy essentially useless. You'll probably want to add
something like seccomp_attr_set(ctx, SCMP_FLTATR_CTL_TSYNC, 1) for
systems with kernel >=3.17; if you have to support seccomp on older
kernels, you'll have to either construct the other threads after
initializing seccomp or manually activate seccomp on those threads.


This shows up in strace as follows:
$ strace -f -e trace=seccomp,clone,prctl
x86_64-softmmu/qemu-system-x86_64 -enable-kvm -drive
file=isos/debian-live-8.7.1-amd64-standard.iso,format=raw -m 4G
-sandbox on -name testvm,debug-threads=on
clone(child_stack=0x7f199af49bf0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7f199af4a9d0, tls=0x7f199af4a700,
child_tidptr=0x7f199af4a9d0) = 10948
strace: Process 10948 attached
[pid 10947] prctl(PR_MCE_KILL, PR_MCE_KILL_SET, PR_MCE_KILL_EARLY, 0, 0) = 0
[pid 10947] clone(child_stack=0x7f199a748bf0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7f199a7499d0, tls=0x7f199a749700,
child_tidptr=0x7f199a7499d0) = 10949
strace: Process 10949 attached
[pid 10947] prctl(PR_SET_TIMERSLACK, 1) = 0
[pid 10947] prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) = 0
[pid 10947] seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL
(Invalid argument)
[pid 10947] seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=39,
filter=0x55a968927830}) = 0
[pid 10947] clone(strace: Process 10950 attached
child_stack=0x7f1999d65bf0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7f1999d669d0, tls=0x7f1999d66700,
child_tidptr=0x7f1999d669d0) = 10950
[pid 10950] prctl(PR_SET_NAME, "CPU 0/KVM") = 0
[pid 10947] clone(strace: Process 10952 attached
child_stack=0x7f1993bfebf0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7f1993bff9d0, tls=0x7f1993bff700,
child_tidptr=0x7f1993bff9d0) = 10952
[pid 10952] prctl(PR_SET_NAME, "worker") = 0
[pid 10947] clone(strace: Process 10953 attached
child_stack=0x7f19933fdbf0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7f19933fe9d0, tls=0x7f19933fe700,
child_tidptr=0x7f19933fe9d0) = 10953
[pid 10953] prctl(PR_SET_NAME, "vnc_worker") = 0
VNC server running on ::1:5900
[pid 10952] +++ exited with 0 +++


Checking in procfs confirms that two of the threads aren't sandboxed:

$ for task in /proc/10947/task/*; do cat $task/comm; grep Seccomp
$task/status; done
qemu-system-x86
Seccomp: 2
qemu-system-x86
Seccomp: 0
qemu-system-x86
Seccomp: 0
CPU 0/KVM
Seccomp: 2
vnc_worker
Seccomp: 2



Re: [Qemu-devel] insecure git submodule URLs

2018-07-15 Thread Jann Horn via Qemu-devel
On Sun, Jul 15, 2018 at 11:18 PM Peter Maydell  wrote:
>
> On 15 July 2018 at 20:50, Jann Horn via Qemu-devel
>  wrote:
> > I noticed that when I build QEMU from git for the first time, it pulls
> > in submodules over the insecure git:// protocol - in other words, as
> > far as I can tell, if I'm e.g. on an open wifi network while building
> > QEMU for the first time, even if I cloned the main repository over
> > https, anyone could smuggle in malicious code as part of e.g. a
> > submodule's makefile.
>
> Yes, this came up the other week.
>
> > I'm not sure what your preferred fix for this is, so I'm not sending a
> > patch yet. As far as I can tell, the two options are:
> >
> >  - change .gitmodules to use https for everything
>
> We should probably do this...
>
> >  - change .gitmodules to use relative URLs
> >
> > If you want, I'll send a patch that does one of these, although it's
> > probably faster if you just do it yourselves.
> >
> > Relative URLs would have the advantage that if someone is cloning from
> > a mirror (in other words, github), the submodules will also
> > automatically come from the same mirror.
>
> Do we mirror all our submodules to github?

Looks that way - I cloned from github, patched my .submodules to use
relative URLs for everything, then tested:

$ git submodule init
Submodule 'capstone' (capstone.git) registered for path 'capstone'
Submodule 'dtc' (dtc.git) registered for path 'dtc'
Submodule 'roms/QemuMacDrivers' (QemuMacDrivers.git) registered for
path 'roms/QemuMacDrivers'
Submodule 'roms/SLOF' (SLOF.git) registered for path 'roms/SLOF'
Submodule 'roms/ipxe' (ipxe.git) registered for path 'roms/ipxe'
Submodule 'roms/openbios' (openbios.git) registered for path 'roms/openbios'
Submodule 'roms/openhackware' (openhackware.git) registered for path
'roms/openhackware'
Submodule 'roms/qemu-palcode' (qemu-palcode.git) registered for path
'roms/qemu-palcode'
Submodule 'roms/seabios' (seabios.git) registered for path 'roms/seabios'
Submodule 'roms/seabios-hppa'
(https://github.com/hdeller/seabios-hppa.git) registered for path
'roms/seabios-hppa'
Submodule 'roms/sgabios' (sgabios.git) registered for path 'roms/sgabios'
Submodule 'roms/skiboot' (skiboot.git) registered for path 'roms/skiboot'
Submodule 'roms/u-boot' (u-boot.git) registered for path 'roms/u-boot'
Submodule 'roms/u-boot-sam460ex' (u-boot-sam460ex.git) registered for
path 'roms/u-boot-sam460ex'
Submodule 'ui/keycodemapdb' (keycodemapdb.git) registered for path
'ui/keycodemapdb'
$ git submodule update
Submodule path 'capstone': checked out
'22ead3e0bfdb87516656453336160e0a37b066bf'
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
Submodule path 'roms/QemuMacDrivers': checked out
'd4e7d7ac663fcb55f1b93575445fcbca372f17a7'
Submodule path 'roms/SLOF': checked out
'7d37babcfa48a6eb08e726a8d13b745cb2eebe1c'
Submodule path 'roms/ipxe': checked out
'0600d3ae94f93efd10fc6b3c7420a9557a3a1670'
Submodule path 'roms/openbios': checked out
'8fe6f5f96f6ca39f1f62200be7fa130e929f13f2'
Submodule path 'roms/openhackware': checked out
'c559da7c8eec5e45ef1f67978827af6f0b9546f5'
Submodule path 'roms/qemu-palcode': checked out
'f3c7e44c70254975df2a00af39701eafbac4d471'
Submodule path 'roms/seabios': checked out
'f9626ccb91e771f990fbb2da92e427a399d7d918'
Submodule path 'roms/seabios-hppa': checked out
'1ef99a01572c2581c30e16e6fe69e9ea2ef92ce0'
Submodule path 'roms/sgabios': checked out
'cbaee52287e5f32373181cff50a00b6c4ac9015a'
Submodule path 'roms/skiboot': checked out
'e0ee24c27a172bcf482f6f2bc905e6211c134bcc'
Submodule path 'roms/u-boot': checked out
'd85ca029f257b53a96da6c2fb421e78a003a9943'
Submodule path 'roms/u-boot-sam460ex': checked out
'60b3916f33e617a815973c5a6df77055b2e3a588'
Submodule path 'ui/keycodemapdb': checked out
'6b3d716e2b6472eb7189d3220552280ef3d832ce'

> > As far as I can tell, the QEMU git server only supports the "dumb" git
> > protocol when accessed over HTTPS, not the "smart" protocol. I'm not
> > sure whether that might be why QEMU is currently still using the
> > insecure git protocol instead of git over HTTPS?
>
> This is why we haven't switched over the submodules yet, yes.
> It's on Jeff's todo list for the server, though.
>
> thanks
> -- PMM



[Qemu-devel] insecure git submodule URLs

2018-07-15 Thread Jann Horn via Qemu-devel
Hi!

I noticed that when I build QEMU from git for the first time, it pulls
in submodules over the insecure git:// protocol - in other words, as
far as I can tell, if I'm e.g. on an open wifi network while building
QEMU for the first time, even if I cloned the main repository over
https, anyone could smuggle in malicious code as part of e.g. a
submodule's makefile.

I'm not sure what your preferred fix for this is, so I'm not sending a
patch yet. As far as I can tell, the two options are:

 - change .gitmodules to use https for everything
 - change .gitmodules to use relative URLs

If you want, I'll send a patch that does one of these, although it's
probably faster if you just do it yourselves.

Relative URLs would have the advantage that if someone is cloning from
a mirror (in other words, github), the submodules will also
automatically come from the same mirror.

As far as I can tell, the QEMU git server only supports the "dumb" git
protocol when accessed over HTTPS, not the "smart" protocol. I'm not
sure whether that might be why QEMU is currently still using the
insecure git protocol instead of git over HTTPS?