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

291–300 of 322 posts

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

#291

Post by worik »

bawolff wrote: post #146
kristopolous wrote: post #132

Earlier quoted context omitted.

Those companies are famous for skullduggery. They can secure the dominance of their offering against the open source competition for well under 500k a year. It's a no brainer. What this might look like would be say, poorly discernable icons, clumsy UI design, or an unstable API that makes plugins constantly break. Large volumes of documentation that are inadequate or inaccurate in critical places, etc. If I was malic…

> Those companies are famous for skullduggery There are levels of skull duggery. Hiring someone to pretend to work for a competitor while secretly sabotaging them is a whole other level of skullduggery with a lot of liability attached. I don't think that would be worth it to them.

> There are levels of skull duggery.

Like shooting a whistle blower?

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

#292

Post by the_why_of_y »

jiggawatts wrote: post #151
ninkendo wrote: post #76

Earlier quoted context omitted.

Some of the checks are there to tell whether or not the compiler even supports your code. You may not be able to compile your code at all, and the job of the build system is sometimes to just emit useful errors to help the person building the code to understand that they need a compiler which supports [language feature X]. Again, this is intended to be portable software. It is designed to work on lots of OS’s, with l…

> Again, this is intended to be portable software. A scathing criticism of the OpenSSL library by the BSD team was that it was too portable in a (very real) sense that it wasn't even written in "C" any more, or targeting "libc" as the standard library. It would be more accurate to say that it was "Autotools/C" instead. By rewriting OpenSSL to target an actual full-featured libc, they found dozens of other bugs, inclu…

OpenSSL is very portable, but it has never used GNU autotools; its Configure is Perl.

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

#294

Post by glandium »

ComputerGuru wrote: post #86
glandium wrote: post #59

Earlier quoted context omitted.

My rule of thumb is that things should never be disabled automatically. Make the test hard fail and print a message that the feature can be disabled.

That’s how you make unusable/uncompilable software. It might be a good rule for something security critical like ssh but not as a general rule.

I'd rather have people complaining about having to run configure a bunch of times to disable several features they don't have the libraries for than complaining that a feature doesn't work (because it ended up being disabled without them knowing).

Likewise, I'd rather distros figure out the hard way when a new release has a new feature and needs a new dependency rather than their users complain that a new feature is missing.

Principle of least surprises.

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

#295

Post by eru »

worik wrote: post #289
eru wrote: post #186

Earlier quoted context omitted.

Well, in C the visual indentation and the meaning of the code (given by {}) can diverge. That's even worse, and happens in practice. Many style guidelines for C have evolved specifically to address that problem with 'the language itself'.

> Well, in C the visual indentation and the meaning of the code (given by {}) can diverge. How?

The compiler doesn't check your indentation at all. (OK, not true, these days you get warnings for misleading indentation.) But here's an example of misleading indentation in C:

    if(some condition)
        do something; {
        do something else;
    }
    do another thing;
You can stretch 'some condition' out over multiple lines and have some more parents inside of it, to make it more confusing.

See also https://softwareengineering.stackexchange.com/a/16530

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

#296

Post by tsimionescu »

kzrdude wrote: post #264
tsimionescu wrote: post #184

Earlier quoted context omitted.

C basically has no standard library. It's no surprise to anyone who has ever used it more than in passing that you depend on the chosen build system to replace that. Building portable C libraries is very different because of this from any other commonly used programming language - even C++.

It's ironic to me to say that C has no standard library while at the same time libc is one of the most important libraries that most programs on an installed system can't go without. So it has one, but it's small. It has a few useful functions, for example system(const char*) which was used by the exploit.

Actually the interaction with libc is not like what you expect from a standard library in other languages. Even apart from being very small, it's not really a single library - you have glibc, musl lib c, the BSDs each have their own libc, Mac OS has its own, Windows has its own. And if you want a very portable C program, you can't assume your program will run with the libc on your system, you need to take into account differences between these. Also, writing C programs that don't use the standard library at all is not unheard of - even apart from C in-kernel or on bare metal. For example, on Windows, libc is just a wrapper over win32, and you can just use that directly and gain much more functionality if you are not going to be portable anyway.

Additionally, libc is typically more of a system component than a part of your program. You can't choose to distribute a libc you prefer with your program and use that, you have to link to the system libc on many OSs. Even on Linux where it's not strictly required, if you use a different libc than the distribution provided one, you can end up in all sorts of problems when you interact with other programs.

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

#297

Post by jiggawatts »

the_why_of_y wrote: post #292
jiggawatts wrote: post #151

Earlier quoted context omitted.

> Again, this is intended to be portable software. A scathing criticism of the OpenSSL library by the BSD team was that it was too portable in a (very real) sense that it wasn't even written in "C" any more, or targeting "libc" as the standard library. It would be more accurate to say that it was "Autotools/C" instead. By rewriting OpenSSL to target an actual full-featured libc, they found dozens of other bugs, inclu…

OpenSSL is very portable, but it has never used GNU autotools; its Configure is Perl.

Which validates my point: OpenSSL is not “C”, it’s not even “Perl”, it’s targeting a bespoke framework and build platform that just so happens to be written in Perl.

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

#298

Post by xorcist »

snnn wrote: post #51

So for each optional feature we may need three build options: 1. Force enable 2. Enable if available 3. Force disable Like, --enable_landlock=always --enable_landlock --disable_landlock

That's ... how autoconf works?

If you explicitly set the enable-landlock flag, configure will fail when the feature doesn't compile.

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

#299

Post by bschwindHN »

patrakov wrote: post #114
phoe-krk wrote: post #7

Earlier quoted context omitted.

So that function checked if the following C code compiled, and only in that situation enabled the landlock? Except that lone period, hard to recognize because of its small size and proximity to the left edge of the diff, caused the C code to become always invalid, hence keeping the landlock always disabled? That's both vilely impressive and impressively vile. I didn't even spot it on my first read-through.

Even more evil would have been to replace this line (void)SYS_landlock_create_ruleset; with this: (void)SYS_landloсk_create_ruleset;

Another point where I appreciate the Rust compiler:

    warning: the usage of Script Group `Cyrillic` in this crate consists solely of mixed script confusables
     --> src/lib.rs:1:4
      |
    1 | fn SYS_landloсk_create_ruleset() {
      |    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
      |
      = note: the usage includes 'с' (U+0441)
      = note: please recheck to make sure their usages are indeed what you want
      = note: `#[warn(mixed_script_confusables)]` on by default
https://play.rust-lang.org/?version=stable&mode=debug&editio...

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

#300

Post by kzrdude »

tsimionescu wrote: post #296
kzrdude wrote: post #264

Earlier quoted context omitted.

It's ironic to me to say that C has no standard library while at the same time libc is one of the most important libraries that most programs on an installed system can't go without. So it has one, but it's small. It has a few useful functions, for example system(const char*) which was used by the exploit.

Actually the interaction with libc is not like what you expect from a standard library in other languages. Even apart from being very small, it's not really a single library - you have glibc, musl lib c, the BSDs each have their own libc, Mac OS has its own, Windows has its own. And if you want a very portable C program, you can't assume your program will run with the libc on your system, you need to take into accoun…

libc is kind of special, but surely many language environments have different standard lib implementations?

Java has OpenJDK and Oracle JDK.

Post reply on HN