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 <
domi...@greysector.net> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to