ulterno

joined 1 year ago
[–] ulterno@programming.dev 9 points 1 week ago (1 children)

OOP can now confidently check the "I'm not a robot" checkbox.

[–] ulterno@programming.dev 3 points 2 weeks ago

Isn't that a bit more than 20 years ago?

[–] ulterno@programming.dev 7 points 2 weeks ago* (last edited 2 weeks ago)

Also, Green on Black is subjectively better than White on Blue.

spoilerNo puns here.
Keep it out of the gutter.

[–] ulterno@programming.dev 0 points 2 weeks ago

On one hand, I thought of policies as the correct way to do stuff, since the user (root) then gets to decide who gets what.
But considering the lack of good enough defaults and that most users won't even know where to look at, I guess we do need additional security features in this case.

For once, it would be good to find a way to reliably let a process (providing said endpoint) know which other process is trying to access said endpoint. This, combined with the root locations (like /bin, /usr/bin etc.) not being writeable without root privileges, should make it possible to have adequate security options in the program itself.

[–] ulterno@programming.dev 2 points 2 weeks ago

So, they were psychopaths who realised they could go unnoticed even more easily if they just took up the religion?

[–] ulterno@programming.dev -2 points 2 weeks ago

I absolutely hate that character. So much that I had to drop the otherwise, mildly interesting series.

[–] ulterno@programming.dev 4 points 2 weeks ago

You worded it better than I would ever have.

[–] ulterno@programming.dev 4 points 2 weeks ago (1 children)

You are thinking too hard.
Just projectile him into position.

[–] ulterno@programming.dev 6 points 2 weeks ago

vaxry talked about LD_PRELOAD and I feel like that is a non-issue in this case.
If an attacker has the ability to modify LD_PRELOAD of an application, they already an ability to modify its behaviour without depending upon what D-Bus may let it do.
And if the attacker can change LD_PRELOAD for a process running as root, they might as well affect the target service directly rather than try doing something with the dbus daemon.

[–] ulterno@programming.dev 1 points 2 weeks ago (2 children)

severe security flaws in D-Bus

I searched for this and all I got was CVEs in the implementations.
What are the flaws in the protocol that I don't know of? If you can link it, I would love to read.

I recently started interacting with code that had something to do with D-Bus and from what I saw, there were policy files, which are required to do anything with D-Bus endpoints provided by software. That's essentially where I stopped, considering that to be the end-all for D-Bus security.

What am I missing?

[–] ulterno@programming.dev 1 points 2 weeks ago

Might as well rewrite Shakespeare in Rust, while we are at it :P

[–] ulterno@programming.dev 4 points 2 weeks ago

prove their worth out of tree until some sort of coherent best practices are established

I feel like this is what the Technical Advisory Board should be replying with.

view more: ‹ prev next ›