xz maintainer just pushed this "CMake: Fix sabotaged Landlock sandbox check." commit https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd...

Which was sneakily introduced here: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2...

Wow, just the process of sneaking in this exploit has layers. Here, it's the presentation of diffs with "+" and "-" line prefixes creating noise that's easy to miss. I bet we'll start seeing tools add a divider between the prefix column and the contents to make changes like this easier to spot.

That said, does GCC accept every non-printing character as whitespace? If not, they could probably have achieved the same thing with a narrow-nonbreaking-space character or similar.

I got curious, so:

     ~/t [main L|…1]$ gcc test.c
     ~/t [main L|…1]$ vi test.c
     ~/t [main L| 1…1]$ git diff
    diff --git a/test.c b/test.c
    index 33c14ce..dc93007 100644
    --- a/test.c
    +++ b/test.c
    @@ -1,3 +1,3 @@
     int main() {
    -    return 0;
    +   return 0;
     }
     ~/t [main L| 1…1]$ gcc test.c
    test.c:2:5: error: expected expression
        <U+0008>return 0;
        ^
    1 error generated.

So, yes, this could have been made to look exactly like a meaningless whitespace change.

Even knowing that it was a dot added, I could not quite easily find this in the diff. Scary...

related to recent events? https://old.reddit.com/r/linux/comments/1brhlur/xz_utils_bac...

On the surface this seems similar to seccomp https://www.man7.org/linux/man-pages/man2/seccomp.2.html

It's way simpler. Seccomp is a pita to keep current and complete. Landlock is higher level with concepts of filesystem locations rather than basic low level ops.

Thanks for explaining. I had tried using seccomp in some previous incarnation, before it allowed passing in ebpf filters, and it was just too restrictive so had to abandon that effort.

Seccomp can't really do this... at least not without serious hacks. I've tried. There are at least two big issues:

* Seccomp intercepts syscalls, and paths are passed to syscalls as pointers. So your code that has to decide "is this syscall allowed?" doesn't get the path, it gets a pointer to a path in another process's address space. That means you have to then pretty much debug that process to find the string. However IIRC there are potential races between when you read the string and when the kernel does.

* Symlinks mean you can't just do a lexical check on the path. Hell you can't even lexically normalise it (remove all `../foo`) because symlinks are crazy. For something like creating files/directories IIRC you have to walk up the path starting from root and read every directory from disk. Like open `/foo`, ok? now open `/foo/bar`, now `/foo/bar/baz`...

Total nightmare. Landlock is much saner for filesystem sandboxing.

Unrelated; this protects the machine for the user, DRM protects it against the user.