[strace/strace] Sudo effective user don't work with --seccomp-bpf (#126)

Dmitry V. Levin ldv at altlinux.org
Tue Feb 25 23:40:16 UTC 2020


On Tue, Feb 25, 2020 at 10:39:33PM +0000, Dmitry V. Levin wrote:
> On Tue, Feb 25, 2020 at 04:05:10AM -0800, Dmytro Kolomoiets wrote:
> > Literally. This works:
> > ```bash
> > $ sudo strace -qqu $USER -e trace=execve -e signal=none -- sudo true
> > 
> > execve("/usr/bin/sudo", ["sudo", "true"], 0x7ffe1fc6b730 /* 13 vars */) = 0
> > ```
> > And this not:
> > ```bash
> > $ sudo strace --seccomp-bpf -fqqu $USER -e trace=execve -e signal=none -- sudo true
> > 
> > execve("/usr/bin/sudo", ["sudo", "true"], 0x7ffc693481d8 /* 13 vars */) = 0
> > sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?
> > 
> > ```
> > Is it temporary regression or `--seccomp-bpf` is fundamentally impossible for this usecase?
> 
> This is a limitation of the current implementation which sets
> PR_SET_NO_NEW_PRIVS unconditionally.  Apparently, in an unlikely case when
> strace is privileged enough, there is no need to set PR_SET_NO_NEW_PRIVS.

Another complication is that strace installs the seccomp filter as late as
possible before execve, that is, strace -u $USER switches to $USER and
therefore drops privileges before installing the seccomp filter, which
means setting PR_SET_NO_NEW_PRIVS in case of strace -u seems to be
unavoidable.


More information about the Strace-devel mailing list