openat() was available before - why they are blaming glibc?

Posted Nov 15, 2017 12:29 UTC (Wed) by sasha (guest, #16070)
Parent article: The inherent fragility of seccomp()

I do not understand why somebody blames glibc at all. There were 2 system calls: open() and openat(). Some "security" filter decided that it wants to prevent user from calling open(), but they forget about openat(). An application may use openat() with any (g|uc|musl)libc, it is just a syscall. So this "security filter" is just stupid and does not provide any security at all. The new glibc release accidentally showed the hole in the filter, thanks you very much. If the developers of this "security filter" blame glibc for this, then it looks... strange.

openat() was available before - why they are blaming glibc?

Posted Nov 16, 2017 8:24 UTC (Thu) by smcv (subscriber, #53363) [Link] (3 responses)

> Some "security" filter decided that it wants to prevent user from calling open(), but they forget about openat().

The situation here seems to be the other way round: a whitelist-based filter allowed a particular program to call the open syscall (and therefore open files), but in recent glibc, the open(2) wrapper function actually uses the more general openat syscall, which the filter didn't allow. This caused that program to become unable to open files - not vulnerable, but also not usable ("failing closed").

openat() was available before - why they are blaming glibc?

Posted Nov 16, 2017 9:19 UTC (Thu) by jem (subscriber, #24231) [Link] (2 responses)

I'm not convinced. I don't think it is fair to blame Glibc for system calls suddenly disappearing from underneath it at the whim of some random system administrator or application developer. If you use drastic tools like seccomp(), you should really know what you are doing and be prepared for surprises like changing library implementations. In the case of open() vs. openat(), I wonder what the reason was for whitelisting one but not the other. Maybe somebody was just sloppy and simply forgot openat() existed?

openat() was available before - why they are blaming glibc?

Posted Nov 16, 2017 13:27 UTC (Thu) by vadim (subscriber, #35271) [Link]

The problem goes as follows:

1. Programmer writes code, wants more protection and decides on the use of seccomp.
2. Programmer looks at what the code needs, and comes up with the 'open' syscall. However the code doesn't call the syscall directly, but the wrapper glibc provides.
3. Code is finished, programmer moves on to the next project.
4. Kernel development goes on, and the 'openat' syscall gets created.
5. Glibc adds usage of openat, and makes it so that in some cases, the glibc provided open wrapper sometimes actually calls 'openat'.
6. In those cases, the previously written code ends up using the 'openat' syscall which is not whitelisted because it didn't exist when the code was written, or because the 'open' wrapper always used the 'open' syscall and nothing else, and this changed later.

The 'open' call doesn't go anywhere. Glibc just doesn't promise to do an exact 1 to 1 wrapper, or not to introduce internal usage of additional new syscalls for its own internal reasons. When you call glibc open(), glibc may actually invoke a new, more advanced syscall like openat instead, or use additional syscalls in the wrapper.

openat() was available before - why they are blaming glibc?

Posted Nov 16, 2017 14:09 UTC (Thu) by corbet (editor, #1) [Link]

This conversation confuses me a bit. Who is blaming glibc? The article is about a particular kernel functionality that is prone to breakage. The term "fragility" in the title was applied to seccomp(), not glibc, after all. I've not seen comments blaming glibc either...?