241–250 of 287 posts
Earlier quoted context omitted.
> At the time they hadn't Their comment was before yours.
if that's the comment you mean, it also misses the point
I'm talking about this comment. Are you talking about this comment? From what knowledge I have, it looks like a good explanation of the problem and why it's not an environment variable problem.
Earlier quoted context omitted.
> And your pulse audio service is running as which user now? I'm not sure, I appear to be running pipewire. But assuming it's not my own account: not a user that will initiate an attack. A user account that allows logins or runs external servers would have to get compromised first, and at that point it can use the exploit directly with no need to touch pulseaudio. If there's only one directory in your /home, it's ver…
Pipewire runs under the pipewire user, managed by systemd or OpenRC. Which means any of their managed processes can start a new pipewire user process. A local priv-sec is one exploit [0] away from a remote one. [0] https://www.bleepingcomputer.com/news/security/hackers-explo...
The box I checked has no pipewire user and it's running under the account I logged in with.
> A local priv-sec is one exploit [0] away from a remote one.
That only matters for accounts that talk to the outside world.
If I'm the only user, I'm not depending on security features to keep my account and the pipewire account safe from each other. Privilege escalation is a big threat for systems that are running in a significantly different way.
Earlier quoted context omitted.
Which "unproven" hypervisors are those? Kata works with Firecracker.
I think they mean in regards to cross kernel attacks. vms didn't protect across speculative execution attacks. I believe there are even more course grained timing attacks with dma and memory that are waiting to be abused.
Earlier quoted context omitted.
Pipewire runs under the pipewire user, managed by systemd or OpenRC. Which means any of their managed processes can start a new pipewire user process. A local priv-sec is one exploit [0] away from a remote one. [0] https://www.bleepingcomputer.com/news/security/hackers-explo...
> Pipewire runs under the pipewire user, managed by systemd or OpenRC. Which means any of their managed processes can start a new pipewire user process. The box I checked has no pipewire user and it's running under the account I logged in with. > A local priv-sec is one exploit [0] away from a remote one. That only matters for accounts that talk to the outside world. If I'm the only user, I'm not depending on securit…
Earlier quoted context omitted.
Yes grsecurity offers actual hardening instead of touting snakeoil.
You are literally saying that hardening the kernel is the same as having the desktop environment hardened and a basis for app isolation. And to add a cherry on top of that both secureblue and kicksecure use almost all the same hardening additions to the linux kernel as grsecurity. You do not understand what you are talking about because if you did you'd be embarrassed for how braindead your response is.
Earlier quoted context omitted.
I presume they're left enabled for root.
The same software that wants to use namespaces for isolation will refuse to run as root.
Earlier quoted context omitted.
It's incredible to me that sudo has that many LoC. I'd assume it would just ask the OS to execute something without restrictions, not have any logic to do so itself.
sudo has a lot of machinery for representing complex policies which involve partial access to elevated (or just different) permissions, and with more conditions than just a correct password for the requesting user. The kernel itself just sees a binary running as root which may drop some of those permissions before starting another process. (And this isn't even the most arcane part of linux userland authorization and…
Earlier quoted context omitted.
> I am pretty sure the Rust version has a lot of logic bugs What makes you say that? I'm not trying to be argumentative, I'm genuinely interested.
I’m a pretty big advocate on Rust and while Rust does protect classes of certain kinds of bugs and probably encourages better unit test hygiene and thus higher code quality, it does not protect against logic bugs and all the historical CVEs and thus it’s possible for previous exploits vectors to resurface. Thus it’s not an unreasonable prior to assume there are vulnerabilities lurking. On the other hand, if the repla…
Earlier quoted context omitted.
All the rewriters are offended by the truth.
Yup, hence why the downvotes. :( I thought it was a no-brainer, but I guess not.
Also does `sudo` not have a spec or any existing unit tests for the previous vulnerabilities that they can benefit from? I'd be pretty shocked if there wasn't a lot of regression testing and documentation available to anyone implementing something this vital.