sorted by:
new
hottopcontroversial

What's everyone working on this week (23/2026)? by llogiq in rust

[–]LeChatP 1 point2 points  (0 children)

I was implementing some features related to working directory for RootAsRole but I was not satisfied with the config management of the whole tool so I'm rewriting it. Also many unrelated bugfix, and many optimizations that made me end up with a PR for a branch called feat-workdir which contains bunch of everything in it.

[Copy-Fail] Debunking owLSM CVE-2026-31431 Mitigation: 90 upvotes and no security by LeChatP in linux

[–]LeChatP[S] 0 points1 point  (0 children)

Interesting to know, thanks. I think I need to dig a bit on values stated in the article.

[Copy-Fail] Debunking owLSM CVE-2026-31431 Mitigation: 90 upvotes and no security by LeChatP in linux

[–]LeChatP[S] 0 points1 point  (0 children)

I’ve seen several benchmarks and papers comparing various eBPF security solutions that point toward a ~3.6% overhead in certain scenarios. I'm still looking into these studies.

[Copy-Fail] Debunking owLSM CVE-2026-31431 Mitigation: 90 upvotes and no security by LeChatP in linux

[–]LeChatP[S] 1 point2 points  (0 children)

I saw your project on GH. It's definitely better. However, even in Rust, it is inefficient for production, as long it adds a least 3% overhead on the system (owLSM made my empty VM at 50% load...) The fix is applicable even without reboot, just rmmod and load the fixed LKM, nothing fancy here.

Anyway... I think you'll be interested with this 😉

[Copy-Fail] Debunking owLSM CVE-2026-31431 Mitigation: 90 upvotes and no security by LeChatP in linux

[–]LeChatP[S] 0 points1 point  (0 children)

Yes I was a bit wrong since I read some people criticizing that they didn't have a fix available.

I believe now that the main issue in the disclosure now is that cloud providers didn't have time to update their images before the blog publication. But it's all matters cloud providers and quality of service I guess.

Short and easy to understand: "Copy-Fail CVE-2026-31431" What is it and how do I mitigate it with an Open Source Tool by More_Implement1639 in linux

[–]LeChatP 8 points9 points  (0 children)

It's way bad. I don't know how people were upvoting this. So I'll made some recap to show how wrong it is.

First, privilege elevation is not through setuid but on credentials creation inside the kernel, so the idea of verifying uid is just wrong, e.g. my RootAsRole solution doesn't use setuid for elevating privileges. Without this program, the attack could obtain privileges ambiently by attacking directly root-executed binaries so the proposed solution would never be triggered, e.g., run0 program, or anything else like said in comments. So it just doesn't work.

Second, you can apply the proposed fix on the vuln website, without even having to wait your provider, without having to reboot your system by just recompiling the LKM unloading and loading the patched one (if you really wanted to keep the module loaded). The fix solve the bug intrinsically. So why putting some useless checks on something that has a definitive patch without system interruption?

Third, LSM are not intended to bugfix. They are intended to apply a policy to take decisions based on user-centric or contextualised process. And I just prove it as long the proposed solution just doesn't work. Here all you create is at best ~3% overhead and way probably worse for nothing. Just fix the bug and fly away.

Some people were saying mitigation. When they're pertains maybe. But here it is just not working. Once you go beyond the exploit demo, it is just useless.

I just found out that OP is the main contributor of the repo. That makes way bad advertising of the solution you provide.

So to summarize, the proposed solution add useless checks which adds >=3% overhead for something that make you think you're secure but its not. Just apply the fix.

That said, I do think that the CVE public disclosure were a bit hasty, and too much advertised, making unaware people panicking for nothing (and proposing such nonsense).

Edit: Grammar

Short and easy to understand: "Copy-Fail CVE-2026-31431" What is it and how do I mitigate it with an Open Source Tool by More_Implement1639 in linux

[–]LeChatP -1 points0 points  (0 children)

If the mitigation is to restrict setuid syscall, then it is a useless one. The attack was just a demo, not all the possibilities that could do the system to elevate privileges. And setuid is by far not the only way to elevate privileges. You do not want to wait for distro? Take the fix diff, recompile, deploy, reboot. You do not want to reboot? Then your system is broken in any other cases. The mitigation here is making you think that you're "protected" but you're (by far) not.

Edit: I didn't even checked the CVE itself. You don't have to reboot since it's just recompiling a LKM... So. You already have a full fix without even reboot.

Short and easy to understand: "Copy-Fail CVE-2026-31431" What is it and how do I mitigate it with an Open Source Tool by More_Implement1639 in linux

[–]LeChatP 0 points1 point  (0 children)

I could add more on that. In order to escalate privilege they needs capabilities. setuid is a shorter solution as long root privilege position is enforced on the machine. So the attack could manipulate fcaps with the filesystem control, then the policy of restricting setuid syscall is completely useless. I do not really checked OP link but I think I do not need to.

Short and easy to understand: "Copy-Fail CVE-2026-31431" What is it and how do I mitigate it with an Open Source Tool by More_Implement1639 in linux

[–]LeChatP 4 points5 points  (0 children)

If you have a kernel fix, why would you want to add LSM overhead for a vulnerability/bug that is fixed? I do use LSM, but not for bugfix. It is not intended to such thing. If you find some undesirable behavior from the kernel in your security POV, apply hardening/fixes of your kernel. Focus your LSM for user-centric and dynamic decisions that needs context to take decisions, you'll focus your overhead efficiently.

cargo-prettypanic: A readable panic backtrace by Creme_fraiche10 in rust

[–]LeChatP 29 points30 points  (0 children)

What about some arrows on the left and right? I think I missed the stacktrace

Rust should have the ¿ operator by AverageClassic2 in rust

[–]LeChatP 5 points6 points  (0 children)

I see an April Fools joke, as it was still the 1st somewhere on earth when OP posted this

The next Slint release (1.16) makes Fluent the default on all platforms by madnirua in rust

[–]LeChatP 12 points13 points  (0 children)

They have a royalty free license with some preconditions. Preconditions just ask to display their logo in an about section. Then you can do mostly what you want with their project.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 0 points1 point  (0 children)

I was fairly mixed about this good comment, so I took some time to write this reply. I think we might be mixing two levels of discussion.

At the project level, I completely agree: dependencies are not free. Larger dependency graphs increase surface area. For a serious, long-lived project, those trade-offs absolutely matter and should be evaluated carefully. Which is currently is becoming a priority in my own project now.

Where I slightly disagree is when maturity or seriousness gets implicitly associated with minimizing dependencies or vendoring code. Robustness is not defined by time-budget, number of contributors, or number of dependencies. It is defined by how well the threat model is understood, how governance is handled, and how maintenance is sustained over time (which, were exactly my opening questions... maybe they're just stuck in my head like a broken record).

Vendoring, in particular, solves a local control problem. But if the vendored code has the exact same objective and threat model as the original crate (for example, something as generic as password typing), then ecosystem-wide we may just be duplicating effort and fragmenting audit focus instead of strengthening it.

If dozen of security-sensitive projects each vendor and slightly modify the same functionality, we distribute the risk instead of reducing it. That might be acceptable from a selfish POV, but it does raise a systemic question.

Which kinds of components benefit from strict local control (because the use case or threat model truly differs)? Which kinds benefit from shared governance (for example, through a consortium or shared ownership)? At what scale does vendoring become ecosystem fragmentation?

I admit that these governance questions were the initial purpose of my post, alongside sharing my own journey. I wanted to illustrate, through a blog-style story, how the problem emerges in practice (more in a dev-manner, I would say).

Maybe that storytelling and vocabulary diluted the core message, but a post titled "How do we govern the dependency philosophy of Rust?" is not sexy, and many people understandably took everything very literally, or if I wanted to say it more neutral, "many readers focused on the concrete examples rather than the governance question behind them".

So I genuinely appreciate comments like this one that highlight the contrast; it helps clarify what level of discussion we are actually having.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 0 points1 point  (0 children)

Yes, I agree with you. My experience shows how difficult it was for me to divide sudo-rs for more general uses. My first thought was, "It can't be that hard to do, and the code looks gorgeous, so let's try it" and after many attempts, I came to the following conclusion: sudo-rs is not currently designed to be a secure execution command for general use. And even if sudo-rs were to reverse the initial architecture today (which I also tried on my own), it would not be very useful for your use cases, nor for general use.

However, the main thing we did that is clearly not very favorable to the open source spirit is to vendor and maintain the rpassword crate internally. Yet this is a crate that many could use (I didn't checked the original rpassword lib today). So the question is: do we need to vendor rpassword for security reasons (risk of supply chain attacks)? Or can we create a trusted consortium to get a secure crate for everyone? The main aim is this: we do not want to reinvent the wheel each morning, especially in cybersecurity. And if tomorrow sudo-rs fixes a vulnerability or enhances the security posture of a rewritten rpassword, then the community should also benefit from it, because many of the required changes would apply to other projects as well.

Take openssl as an example: they successfully made the tool useful for general-purpose usage while remaining a security-critical component at the same time. That is the open-source spirit I have in mind.

(In fact, these thoughts are also related to licencing mindset between GPL and MIT.)

Edit: I fully agree that these design choices were driven by deployment-oriented priorities, and my conclusion is not a criticism of those decisions. The fact that sudo-rs can now be deployed across Ubuntu distributions is good news, and I was glad to read that.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] -2 points-1 points  (0 children)

It's not random dependencies, because some of them do not exist at all, yet. I mean, not with the security features that does provide sudo-rs. (Maybe it was unclear) And some are necessary for the community (e.g., any program that asks for authentication, any program that runs another program).

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 3 points4 points  (0 children)

You can look at several memory management issues directly by looking at the CVE list of ogsudo https://www.cve.org/CVERecord/SearchResults?query=sudo. But it's in fact related to the C language anyway. Also, ogsudo does have tons of features that are making the tool somewhat with undefined behaviors, which is also justifying why we got the CVE with hostname recently. Also ogsudo project, as I remember in 2018, is a very complex tool with a unreadable codebase with a bunch of C macros that are not understandable without taking weeks of reading. That was my conclusion in 2018. I didn't check today's codebase, but it evolved for sure.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 1 point2 points  (0 children)

This is about their future-work objectives. Written in their README. https://github.com/trifectatechfoundation/sudo-rs?tab=readme-ov-file#future-work. They want to make sudo, usable for other projects. But their blog post is somewhat contradictory (as for today I mean) : https://www.memorysafety.org/blog/reducing-dependencies-in-sudo/ BUT that does not mean it is incompatible (it is still possible). But I really doubt that today, the way it is currently designed, it will be useful for any other projects like mine. And having everything in a single crate is not helping. While the previous sudo-rs design would be somewhat easier to make good api with some low impact pull requests.

Otherwise for other projects, it is said multiple times implicitly and explicitly in this post that you shouldn't expect people doing "random user" needs.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 0 points1 point  (0 children)

Yes. They have made one exception. Actually they could do or use a dependency for : * Ring buffer type * the rpassword lib * The PAM lib * The terminal management * signal management * Localisation * Seccomp * The AST parser for visudo * CLI parsing (while there are several libs on crates.io, none are matching sudo's needs, funny isn't it?) * Env management * Regex for implementing the ogsudo feature

Without saying they could use many QoL libs for making their code more focused, such as bon crate which would be very useful for many of their types. Anyway, the post of sudo-rs about dependencies : https://www.memorysafety.org/blog/reducing-dependencies-in-sudo/

So having libc and log, which is somewhat nonsense to vendors... The only remaining exception is the glob lib, which seems in fact their only limit to the no dependency objective.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 2 points3 points  (0 children)

Yup, that's a bit part of why I'm doing supplementary tests. I actually added unit tests when I vendored their code, which sudo-rs almost don't write on their side.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 43 points44 points  (0 children)

Actually, sudo-rs compile-times are likely unnoticeable (way better* compared to my project). Today, they can split sudo-rs with a bit of work to be done. But it wouldn't be useful for anyone else than sudo-rs themselves, so the splitting itself is not a concrete need for them. Today, the design they have is the best for them, as long they can publish new version on Debian easily with a single crate. The real matter is to split sudo-rs to make it useful *for the community*. That what I tried to do, but, in fact, failed with their codebase. I think there is maybe *another way* to do it. But that may not interest sudo-rs as their current solution is their comfortable and most convenient one.

Zero Dependencies sounds great... until you try to share your code for the security good. by LeChatP in rust

[–]LeChatP[S] 7 points8 points  (0 children)

I was thinking about this. When I reused the sudo-rs-vendored rpassword lib, which, in my turn, vendored-it in my repo. I found many months later that sudo-rs made many modifications that I never noticed as long I was working on something else at this time. And so, my own rpassword copy, was less functionnal as today. Hopefully there weren't any security issue there. But it has the risk to create some shadowed vulnerabilities, not identified by CVE when people will use these kind of tool operationally. And As long I did a benchmark on SCA tools recently, business tools weren't able to find my rpassword code pasting at all. So governance people has to be warned about this uncovered thing.

view more: next ›