NekkoDroid

joined 1 year ago
[–] NekkoDroid@programming.dev 2 points 6 months ago

bless the drive with a boot loader that doesn’t suck, like Grub

Ah yes, I need a whole separate OS just to boot my actual OS...

I would in no world call GRUB a bootloader that doesn't suck.

[–] NekkoDroid@programming.dev 3 points 6 months ago

I don’t understand how this is any improvement over pkexec

That has the same problem as sudo: the SUID bit is set for it.

The fact that run0 uses polkit is more of a byproduct that this kinda authentication is already done with polkit all over the place in systemd. You can have individual subcommand accessible to different users (for example everyone can systemctl status, but systemctl reboot needs to be in the wheel group) which is why its generally used within systemd already. And it wouldn't surprise me if again you can do it with this as well, limiting what commands can unconditionally run, need prompt or are completely blocked.

[–] NekkoDroid@programming.dev 1 points 6 months ago

I don't know, unless I personally allow the admin to have that kinda access to my files I wouldn't really want it. And for that case you can enroll recovery keys (which would need to be manually stored, but still) or a fido token or whatever other supported mechanism there is, its LUKS2 backed encryption after all. Then there is also the possibility to just not encrypt the home directory at all.

[–] NekkoDroid@programming.dev 3 points 6 months ago
  1. The attack surface is there either way, this is just functionality repackaged that existed already before (systemd-run, which is calling into PID1)
  2. all compression libraries (actually most libraries at this point) are dlopened on demand (which was planned even before the attack, which is speculated that the attack was accelerated in timeline because he was on a timer before the change was released)
[–] NekkoDroid@programming.dev 3 points 6 months ago (7 children)

Sure, the other option is having it tied to an email, which is reliant on your single vendor and is also an easier way to create an army of spam bots. Phone numbers at least are transferable between carriers.

[–] NekkoDroid@programming.dev 7 points 6 months ago (2 children)

I guess my interpretation was too charitable.

Nothing in the protocol prevents you from splitting the server from the window manager, just everyone implementing the wayland server protocol didn't see any benefit in splitting it out.

[–] NekkoDroid@programming.dev 3 points 6 months ago (4 children)

I think what they meant is that there are people that think: "Wayland is too fragmented, there should be 1 'Wayland Compositor' and the rest should be window managers"

[–] NekkoDroid@programming.dev 20 points 6 months ago* (last edited 6 months ago) (3 children)

This isn't exactly a "new" attack surface, so removing the attack surface that sudo (and alternatives) is, is probably a net positive.

[–] NekkoDroid@programming.dev 4 points 6 months ago

it does its authorization with polkit (which IIRC defaults to allow all wheel group members) and giving users that shouldn't be allowed root access, root access, is not something you ever want. This is usually referred to as unauthorized privilege escalation. Also, it isn't like sudo doesn't need configuration.

[–] NekkoDroid@programming.dev -3 points 6 months ago (1 children)

One way to notice a person has "systemd derangement syndrome" is by looking at how they write systemd: if they write it SystemD they are already in late stages of SDS and it isn't curable anymore.

[–] NekkoDroid@programming.dev 7 points 6 months ago* (last edited 6 months ago) (9 children)

homed isn't exactly a home directory replacement, more of an extension. You can mix and match homed and normal home directories like you want (on a per-user basis at least, not within a single user). It does have some nice things, such as user-password based encryption of the home directory, so the password is required to unlock it (no admin access) or automatically using subvolumes on btrfs.

[–] NekkoDroid@programming.dev 9 points 6 months ago* (last edited 6 months ago) (2 children)

The thing with this is: its just a symlink to the systemd-run binary, which talks to PID1 to spawn new processes (in separate cgroups IIRC). Its one of the most fundamental parts of systemd. Even the debian systemd package includes systemd-run.

I guess the other question is if some tools the distro provides might switch to supporting it by default. For example on Arch there is makepkg that should never be executed as root, but does internally call some things with elevated privileges (mostly pacman to install and remove packages). Currently it checks for sudo and if not falls back to su, but maybe it might be worth considering changing su for run0 if its guaranteed to be there.

view more: ‹ prev next ›