4 ms·
Landlock: Unprivileged Access Control
- fifteen1506 3y agoCool, more security mechanisms. In return, can I now use Skyshowtime on Linux?
- yjftsjthsd-h 3y agoUnrelated; this protects the machine for the user, DRM protects it against the user.
- MawKKe 3y agorelated to recent events? https://old.reddit.com/r/linux/comments/1brhlur/xz_utils_backdoor/kx9b9wc/ https://old.reddit.com/r/linux/comments/1brhlur/xz_utils_bac...
- rdtsc 3y agoOn the surface this seems similar to seccomp https://www.man7.org/linux/man-pages/man2/seccomp.2.html https://www.man7.org/linux/man-pages/man2/seccomp.2.html
- viraptor 3y agoIt'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.
- rdtsc 3y agoThanks 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.
- IshKebab 3y agoSeccomp 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.
- alpb 3y agoxz maintainer just pushed this "CMake: Fix sabotaged Landlock sandbox check." commit https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00;hp=af071ef7702debef4f1d324616a0137a5001c14c https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd...
- radicality 3y agoWhich was sneakily introduced here: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7 https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2...
- sega_sai 3y agoEven knowing that it was a dot added, I could not quite easily find this in the diff. Scary...
- tadfisher 3y agoWow, 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.
- thenewwazoo 3y agoI 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.