minijail0 doesn't appear to enforce seccomp policies against Go programs |
||
Issue description
I'm having trouble with minijail0 seemingly not honoring a seccomp policy when I run a Go program. I'm running the following command (which relies on some uncommitted code in Tast) on a lumpy device:
/sbin/minijail0 -S /usr/local/share/tast/data_pushed/chromiumos/tast/local/bundles/cros/security/data/minijail_seccomp_policy /usr/local/libexec/tast/bundles/local_pushed/cros -subproc=security.MinijailSeccomp_Fail -subprocargs=null
It runs the program to completion and exits with 0.
minijail_seccomp_policy contains the following:
openat: 1
read: 1
close: 1
exit: 1
exit_group: 1
When I run the "cros" command under strace, I can see that it's calling write() -- see the writes to /dev/null and to stderr in the attached file.
Any ideas why minijail0 isn't killing the program and exiting with 253 when it sees the write call?
I'm not super-familiar with minijail0's operation, but I believe that hooks these calls using LD_PRELOAD, so maybe something is wrong there.
localhost ~ # ldd /usr/local/libexec/tast/bundles/local_pushed/cros
linux-vdso.so.1 (0x00007ffc9a13e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007efe4bf7c000)
libc.so.6 => /lib64/libc.so.6 (0x00007efe4bbd1000)
/lib64/ld-linux-x86-64.so.2 (0x00007efe4c199000)
(I'm not sure that this Go program would work for what I was hoping to use it for in any case, since it looks like Go makes a bunch of additional system calls at startup even for a trivial "hello, world" program. But I'd still like to know why minijail0 isn't working as expected here.)
,
Dec 27
please attach all the files you're testing with
,
Dec 27
I'm not able to repro this with a reduced test case. I can try uploading some in-progress changes that were triggering it, but it's more involved to repro there. Here's the reduced test case: GOPATH=/usr/lib64/gopath x86_64-cros-linux-gnu-go build -o /tmp/write_example /tmp/write_example.go Copy write_example to /usr/local/bin and policy to /tmp on a caroline device, then run: /sbin/minijail0 -S /tmp/policy /usr/local/bin/write_example I see exit code 253 in this case, and dmesg points at syscall 204, which is sched_getaffinity per "minijail -H", which I think is called internally by Go. Side question: does the -L flag described at https://chromium.googlesource.com/chromiumos/docs/+/master/sandboxing.md#Seccomp-filters still work correctly? When I run "/sbin/minijail0 -S /tmp/policy -L /usr/local/bin/write_example", I don't see anything about the blocked syscall in /var/log/messages. I just see the following: 2018-12-27T23:04:25.330080+00:00 NOTICE kernel: [ 9370.333812] audit: type=1400 audit(1545951865.328:85122): avc: granted { execute } for pid=16110 comm="bash" name="minijail0" dev="dm-0" ino=61462 scontext=u:r:cros_ssh_session:s0 tcontext=u:object_r:cros_minijail_exec:s0 tclass=file 2018-12-27T23:04:25.331078+00:00 NOTICE kernel: [ 9370.334514] audit: type=1400 audit(1545951865.329:85123): avc: granted { execute } for pid=16110 comm="minijail0" path="/sbin/minijail0" dev="dm-0" ino=61462 scontext=u:r:cros_ssh_session:s0 tcontext=u:object_r:cros_minijail_exec:s0 tclass=file 2018-12-27T23:04:25.333250+00:00 WARNING minijail0[16110]: libminijail[16110]: allowing syscall: socket 2018-12-27T23:04:25.333312+00:00 WARNING minijail0[16110]: libminijail[16110]: allowing syscall: connect 2018-12-27T23:04:25.333331+00:00 WARNING minijail0[16110]: libminijail[16110]: allowing syscall: sendto 2018-12-27T23:04:25.333346+00:00 WARNING minijail0[16110]: libminijail[16110]: allowing syscall: writev 2018-12-27T23:04:25.339460+00:00 WARNING write_example[16111]: libminijail[16111]: logging seccomp filter failures 2018-12-27T23:04:25.367641+00:00 INFO crash_reporter[16112]: libminijail[16112]: mount '/dev/log' -> '/dev/log' type '' flags 0x1001 2018-12-27T23:04:25.373132+00:00 DEBUG kernel: [ 9370.377125] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs 2018-12-27T23:04:25.383068+00:00 DEBUG kernel: [ 9370.387084] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs 2018-12-27T23:04:25.391851+00:00 WARNING crash_reporter[16112]: [user] Received crash notification for write_example[16111] sig 31, user 0 group 0 (developer build - not testing - always dumping) 2018-12-27T23:04:25.395388+00:00 INFO crash_reporter[16112]: State of crashed process [16111]: S (sleeping) 2018-12-27T23:04:25.396470+00:00 INFO crash_reporter[16112]: Accessing crash dir '/var/spool/crash' via symlinked handle '/proc/self/fd/5' 2018-12-27T23:04:25.402127+00:00 INFO metrics_daemon[3328]: [INFO:metrics_daemon.cc(494)] Got org.chromium.CrashReporter.UserCrash D-Bus signal 2018-12-27T23:04:25.416500+00:00 INFO crash_reporter[16112]: Stored minidump to /var/spool/crash/write_example.20181227.150425.16111.dmp 2018-12-27T23:04:25.416841+00:00 INFO crash_reporter[16112]: Leaving core file at /proc/self/fd/5/write_example.20181227.150425.16111.core due to developer image 2018-12-27T23:04:25.417246+00:00 WARNING crash_reporter[16112]: [ARC] Received crash notification for write_example[16111] sig 31, user 0 group 0 (ignoring - crash origin is not ARC) 2018-12-27T23:04:25.425582+00:00 WARNING minijail0[16110]: libminijail[16110]: child process 16111 received signal 31
,
Dec 27
If you're cool with running a compiled executable on your DUT, I uploaded a 12 MB amd64 binary (the "cros" Tast test bundle) to https://drive.google.com/file/d/1R78VVWpCkG5O2qEJjYnTcOs2h7qVKAWv/view?usp=sharing. When I run "strace /path/to/binary -subproc=security.MinijailSeccomp_Fail" on a caroline device, I see it perform multiple writes. When I run "/sbin/minijail0 -S /path/to/policy -- /path/to/binary -subproc=security.MinijailSeccomp_Fail" using the policy from #3 (which doesn't permit writes), I see the process run to completion with a 0 exit code. Am I doing something wrong?
,
Jan 2
-L might not work if go is messing with the signal handlers. We use a signal handler to print the failing syscall to syslog. Also, just try with -T static to force minijail into static executable mode to avoid using LD_PRELOAD. |
||
►
Sign in to add a comment |
||
Comment 1 by derat@chromium.org
, Dec 27