https://bugs.chromium.org/p/chromium/issues/detail?id=1164975
Please add in this info, it was on my TODO list, but clearly hasn't happened yet.
~spot
On Wed, Jan 13, 2021 at 8:33 AM Dominik 'Rathann' Mierzejewski <dominik@xxxxxxxxxxxxxx> wrote:
On Wednesday, 13 January 2021 at 03:14, Kevin Kofler via devel wrote:
> Florian Weimer wrote:
> > Right, and the glibc 2.33 versions all call fstatat64 in the end (system
> > call number 0x106).
>
> That would be:
>
> #if !defined(__NR_newfstatat)
> #define __NR_newfstatat 262
> #endif
>
> from:
>
> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/system_headers/x86_64_linux_syscalls.h
>
> > The older x versions call the earlier system calls
> > (numbers 4, 5, 6)
>
> And these are defined as:
>
> #if !defined(__NR_stat)
> #define __NR_stat 4
> #endif
>
> #if !defined(__NR_fstat)
> #define __NR_fstat 5
> #endif
>
> #if !defined(__NR_lstat)
> #define __NR_lstat 6
> #endif
>
> I see that the sandbox is treating __NR_newfstatat as IsFileSystem, like
> __NR_stat and __NR_lstat, whereas __NR_fstat is under
> IsAllowedFileSystemAccessViaFd. So the issue is that everything now calls
> the same syscall under the hood, so the sandbox can no longer distinguish
> the two access types just by looking at the syscall ID.
>
> The baseline policy disallows everything under IsFileSystem and allows only
> IsAllowedFileSystemAccessViaFd:
> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc
> (i.e., __NR_fstat is allowed, whereas __NR_stat, __NR_lstat, and
> __NR_newfstatat are not).
I think you wanted to link
https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc
here instead.
__NR_newfstatat is at line 116 and __NR_fstat is at line 170. Note that
plain __NR_stat and __NR_lstat are also rejected (lines 101 and 94).
> It looks like it needs to restrict the arguments to __NR_newfstatat (to an
> empty path and the AT_EMPTYPATH flag) instead of rejecting it outright, so
> that fstat keeps working, see:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=io/fstat.c;h=dc117361ffe7064be7c6746465388803e203adcf;hb=HEAD
Is there an upstream bug open for this already?
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
