Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xz: Can you spot the single character that disabled Linux landlock?

git.tukaani.org

Post reply on HN
Print view View original

61–70 of 322 posts

Re: Xz: Can you spot the single character that disabled Linux landlock?

#61

Post by raimue »

viraptor wrote: post #56
clnhlzmn wrote: post #50

Would it be reasonable to expect that this MR comes along with a test that shows that it does the thing it’s claiming to do? I’m not sure how that would work in this case.. have a test that is run on a system that is known to have landlock that does something to ensure that it’s enabled? Even that could be subverted, but it seems like demanding that kind of thing before merging “features” is a good step.

I'd say this MR is a bad approach in general. The headers say what interfaces are known, not what features are available. You should be able to compile with landlock support on a system which doesn't enable it. Same situation as seccomp and others. Your build machine doesn't have to match the capabilities of the target runner. But yeah, to test it, you can have a mock version of landlock which responds with the error…

Read the code of the check again. It mostly checks that the required SYS_* constants are defined to be able to use the syscalls. You can compile this on a system that does not have landlock enabled in the running kernel, but the libc (which imports the kernel system call interface) has to provide the syscall numbers.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#62

Post by pas »

karmakaze wrote: post #15

I can't believe that system security is dependent on such a loose chain of correctness. Any number of things could have stopped this. + # A compile check is done here because some systems have + # linux/landlock.h, but do not have the syscalls defined + # in order to actually use Linux Landlock. Fix those headers on those systems to explicitly opt-out. What's the point of headers if they don't declare their capabilit…

... there's a huge bias in things that get tested (and how they get tested). easy to test things get tested. there's a lot more developer, committer, maintainer for web stuff. there's a cultural issue, it's hard to improve on old ossified processes/projects, etc.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#63

Post by Hnrobert42 »

karmakaze wrote: post #15

I can't believe that system security is dependent on such a loose chain of correctness. Any number of things could have stopped this. + # A compile check is done here because some systems have + # linux/landlock.h, but do not have the syscalls defined + # in order to actually use Linux Landlock. Fix those headers on those systems to explicitly opt-out. What's the point of headers if they don't declare their capabilit…

As a user of open source who doesn’t know enough to make those suggestions, I would be grateful if you would develop and contribute them.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#64

Post by Aeolun »

dhx wrote: post #2

Answer: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd... Description of Linux's Landlock access control system if you are not familiar with it: https://docs.kernel.org/userspace-api/landlock.html xz official (maybe...) incident response page: https://tukaani.org/xz-backdoor/

I feel like my version control system is better about highlighting the changed characters than these solid green or red strings.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#65

Post by TheRealPomax »

Aeolun wrote: post #64
dhx wrote: post #2

Answer: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd... Description of Linux's Landlock access control system if you are not familiar with it: https://docs.kernel.org/userspace-api/landlock.html xz official (maybe...) incident response page: https://tukaani.org/xz-backdoor/

I feel like my version control system is better about highlighting the changed characters than these solid green or red strings.

It's git, so it can show a vastly better diff, just not from a URL with hardcoded diff settings.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#66

Post by viraptor »

raimue wrote: post #61
viraptor wrote: post #56

Earlier quoted context omitted.

I'd say this MR is a bad approach in general. The headers say what interfaces are known, not what features are available. You should be able to compile with landlock support on a system which doesn't enable it. Same situation as seccomp and others. Your build machine doesn't have to match the capabilities of the target runner. But yeah, to test it, you can have a mock version of landlock which responds with the error…

Read the code of the check again. It mostly checks that the required SYS_* constants are defined to be able to use the syscalls. You can compile this on a system that does not have landlock enabled in the running kernel, but the libc (which imports the kernel system call interface) has to provide the syscall numbers.

You're right. I didn't see SYS... symbols being actually used, but they are: https://git.tukaani.org/?p=xz.git;a=blob;f=src/xz/sandbox.c;...

This doesn't change my opinion in general - that version should be exposed through a library call and knowing about the specific syscalls shouldn't be needed in xv.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#67

Post by Aeolun »

ninkendo wrote: post #32
jijijijij wrote: post #27

Earlier quoted context omitted.

Is this by design, or by legacy? I mean, is there a better way to do this? Seems really flawed to me.

It’s by design. The job of autotools is to find “ground truth” about whatever environment you’re compiling against. It’s meant to discover if you can use a feature by actually seeing whether it works, not just by allow-listing a known set of compiler or library versions. This is because the whole point is to allow porting code to any environment where it’ll work , even on compilers you don’t know about. Think back to…

I don’t know. In my code I’d always compile and check at runtime?

Re: Xz: Can you spot the single character that disabled Linux landlock?

#68

Post by trelane »

ColonelPhantom wrote: post #53
trelane wrote: post #47

I wonder why it was useful to prevent Landlock from being enabled in xz. Perhaps a later stage was to inject malicious content into xz archives? But then why not just inject malicious activity in xz itself?

Because a deliberate vulnerability is much easier to hide than actual malicious content. One could probably sneak a buffer overflow or use-after-free into a C project they maintain without being noticed. Actually shipping a trojan is much harder, as observed with the xz-to-sshd backdoor.

Ah, so the next stage would have been to add a "bug" in xz that would trigger during the supposedly sandboxed execution, when presented with certain input files. Clever.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#69

Post by Denvercoder9 »

Aeolun wrote: post #67
ninkendo wrote: post #32

Earlier quoted context omitted.

It’s by design. The job of autotools is to find “ground truth” about whatever environment you’re compiling against. It’s meant to discover if you can use a feature by actually seeing whether it works, not just by allow-listing a known set of compiler or library versions. This is because the whole point is to allow porting code to any environment where it’ll work , even on compilers you don’t know about. Think back to…

I don’t know. In my code I’d always compile and check at runtime?

Not everything is detectable at runtime, such as syscall numbers (which is what's being tested for here).

Re: Xz: Can you spot the single character that disabled Linux landlock?

#70

Post by cryptonector »

jijijijij wrote: post #27
ronsor wrote: post #26

Earlier quoted context omitted.

> Is a compilation-test a legitimate/common/typical method to go about this? Yes—in fact, compilation tests are often the only way you can tell if a feature actually works. It's extremely common for C build systems to detect and work around weird systems.

Is this by design, or by legacy? I mean, is there a better way to do this? Seems really flawed to me.

It's not by design, unlike what siblings say. It's by accident (so, "legacy", as you put it).

The problem is that already in the 80s there was tons of variability from on Unix system (or version of it) to the next, but there was no standard way of representing what features/standards/APIs/libraries a system supported or had installed. When faced with such a mess people wrote code to detect features are present on the target host.

This then got made into tools with libraries of detection code. Think autoconf/autotools.

Now we also have pkgconfig, but it's too late and it was not enough anyways.

Some things you might only detect at run-time, provided that their ABIs are stable enough that you can copy their headers into your application.

Post reply on HN