2025-12-09 00:08:28 <jvoisin> ncopa: I just tagged fortify-headers 3.0
2025-12-09 00:08:48 <jvoisin> do you want to play a bit with it, or shall I simply send a merge-request in aports?
2025-12-09 13:15:51 <achill> do you have a idea how to proceed with the sudo-rs MR?
2025-12-09 13:15:59 <achill> cc ikke
2025-12-11 23:00:36 <Ariadne> i am super skeptical on sudo-rs
2025-12-11 23:00:59 <Ariadne> the security problem with sudo is the combinational complexity of the sudo config, not memory safety
2025-12-11 23:01:10 <Ariadne> but its no worse than sudo itself, which we also carry
2025-12-12 01:22:14 <achill> for me personally, its basically a "better sudo" for people who want to use something sudo-compatible
2025-12-12 01:32:27 <idkrnx[m]> Ariadne: Memory corruption has been abused in sudo to escalate privileges before
2025-12-12 01:34:11 <idkrnx[m]> Bare minimum sudo should only have execute permissions for users that are are allowed to become root
2025-12-12 02:00:50 <Ariadne> idkrnx[m]: ok, and?  the larger problem is still that sudo is too complex.  it has PLUGINS for fucks sake
2025-12-12 02:01:37 <idkrnx[m]> The memory unsafety cannot be ignored
2025-12-12 02:03:01 <idkrnx[m]> <idkrnx[m]> "Bare minimum sudo should only..." <- Or at the very least parsing needs to be done from a low privilege process in a address space
2025-12-12 02:03:57 <idkrnx[m]> * in a different address space
2025-12-12 03:13:13 <Ariadne> i am not saying it should be ignored, i am saying that the design of sudo itself is flawed
2025-12-12 03:13:34 <Ariadne> memory safety was not why alpine switched to doas, for example
2025-12-12 05:54:52 <idkrnx[m]> Ariadne: Yes sudo is atrocious for standard users
2025-12-12 05:56:12 <idkrnx[m]> Ariadne: I don't think the reason is too dissimilar. Complex logic can lead to memory corruption
2025-12-12 05:56:49 <idkrnx[m]> Ariadne: But I agree that the logic bugs are equally as severe and perhaps more frequently abused
2025-12-12 06:24:26 <Ariadne> i guess my point here is that sudo-rs seems like another "rewrite it in rust" project, where the cure is "rewrite it in rust" rather than a more careful examination of why sudo is flawed
2025-12-12 06:25:25 <Ariadne> privilege escalation should be done with object capabilities anyway
2025-12-12 06:27:30 <Ariadne> building forests of ACLs are error prone, you either have logic errors in the policy engine or you have user errors in the config file
2025-12-12 06:27:50 <Ariadne> or in the case of C sudo... both :)
2025-12-12 06:29:41 <Ariadne> i'll elaborate tomorrow, i started sketching something a year ago that is shaped more like "the right thing", but got busy with real life
2025-12-12 06:30:01 <Ariadne> may as well finish it, $dayjob work for this week is over
2025-12-12 06:57:54 <idkrnx[m]> Ariadne: It's probably easier to just deny sudo/doas to anyone not in the right group
2025-12-12 06:58:28 <Ariadne> it's easier than that
2025-12-12 06:58:33 <Ariadne> if that's all you want
2025-12-12 06:58:44 <idkrnx[m]> What could be easier?
2025-12-12 06:59:35 <Ariadne> in an object-capability model approach you would have a daemon (or supervisor that can forward a listener on demand like systemd socket activation i guess) that listens on a unix socket that belongs to a group
2025-12-12 06:59:40 <Ariadne> client connects to socket
2025-12-12 06:59:44 <Ariadne> SCM_RIGHTS bla bla
2025-12-12 06:59:51 <idkrnx[m]> Uhh how is that easier?
2025-12-12 07:00:07 <Ariadne> eliminates the suid part
2025-12-12 07:00:18 <Ariadne> su/sudo/doas have to be suid because they are special ;)
2025-12-12 07:00:23 <idkrnx[m]> But my way requires almost no engineering whatsoever
2025-12-12 07:00:38 <Ariadne> yeah mine doesn't either cause i sketched it a year and a half ago
2025-12-12 07:01:01 <idkrnx[m]> And you didn't implement it because it was so easy right? :)
2025-12-12 07:01:04 <Ariadne> i did implement it
2025-12-12 07:01:23 <Ariadne> i just didn't get around to dealing with job control bs
2025-12-12 07:01:24 <idkrnx[m]> Ariadne: You got busy?
2025-12-12 07:01:36 <Ariadne> yes, i am quite busy
2025-12-12 07:01:44 <idkrnx[m]> Ariadne: So it's not easier :)
2025-12-12 07:02:00 <idkrnx[m]> This just a chmod and a chown :)
2025-12-12 07:02:18 <Ariadne> like i said, i sketched it last year: https://github.com/kaniini/capsudo
2025-12-12 07:02:27 <idkrnx[m]> Ariadne: I wasn't doubting that. I was just explaining why I said you didn't implement it
2025-12-12 07:02:29 <Ariadne> i'm actively writing the job control bs right now
2025-12-12 07:02:39 <idkrnx[m]> Ariadne: Oh I remember I think you linked me that a long time ago
2025-12-12 07:03:16 <idkrnx[m]> Ariadne: Just avoid the bs and let chmod lead the way!
2025-12-12 07:03:28 <Ariadne> well you need the job control bs
2025-12-12 07:03:54 <idkrnx[m]> Why would you need that if only allowed users can execute?
2025-12-12 07:04:13 <Ariadne> sorry, by job control i mean TTY stuff
2025-12-12 07:04:22 <idkrnx[m]> Oh
2025-12-12 07:04:27 <Ariadne> like the current implementation just sends over the TTY FDs over SCM_RIGHTS
2025-12-12 07:04:32 <Ariadne> but you have to proxy it technically
2025-12-12 07:04:44 <Ariadne> due to ... certain limitations of the Unix tty model
2025-12-12 07:04:49 <idkrnx[m]> Why is that necessary in my solution?
2025-12-12 07:05:00 <Ariadne> it's not, but you have suid binary
2025-12-12 07:05:38 <idkrnx[m]> I mean that would have nearly zero impact if only privileged users had access
2025-12-12 07:05:53 <Ariadne> sure
2025-12-12 07:06:18 <Ariadne> i'm not saying a simple doas config that permits wheel users is bad
2025-12-12 07:06:22 <idkrnx[m]> idkrnx[m]: Only someone with RCE but no keylogging would benefit
2025-12-12 07:06:38 <Ariadne> i'm just saying we can do better
2025-12-12 07:06:46 <idkrnx[m]> Ariadne: I like it because it is trivial for every distro to implement
2025-12-12 07:06:53 <Ariadne> so is capsudo
2025-12-12 07:07:21 <idkrnx[m]> Ariadne: But you're still working on it?
2025-12-12 07:07:39 <idkrnx[m]> There's nothing to work on in my case
2025-12-12 07:07:49 <Ariadne> i'm in it for the love of the game
2025-12-12 07:07:53 <idkrnx[m]> It's an instant improvement
2025-12-12 07:08:16 <idkrnx[m]> Ariadne: You have my respect
2025-12-12 07:08:42 <idkrnx[m]> But I don't think the game loves you back :(
2025-12-12 07:08:42 <Ariadne> i recently got on uhh
2025-12-12 07:09:27 <idkrnx[m]> Desktop apps just expect access to everything and users do too
2025-12-12 07:09:54 <Ariadne> viloxazine?
2025-12-12 07:09:58 <Ariadne> yes, that
2025-12-12 07:10:17 <idkrnx[m]> I remember seeing somewhere on matrix someone had errors with git and just ran sudo git 😭
2025-12-12 07:10:58 <Ariadne> look we can't fix stupid
2025-12-12 07:11:20 <idkrnx[m]> Ariadne: They can't do this on an iPhone
2025-12-12 07:11:30 <idkrnx[m]> That's how you fix it :)
2025-12-12 07:11:40 <Ariadne> sure
2025-12-12 07:12:03 <Ariadne> and i think some pmOS folks are working on a similarly immutable distribution
2025-12-12 07:12:20 <Ariadne> so you give that to non-technical users and they can't break their computers anymore
2025-12-12 07:12:39 <Ariadne> well, at least the OS image
2025-12-12 07:12:39 <idkrnx[m]> Just use Fedora atomic?
2025-12-12 07:13:26 <Ariadne> i would say bazzite over that, since most casual users just want to run steam and a browser and other flatpak stuff
2025-12-12 07:13:30 <idkrnx[m]> Ariadne: It slightly bothers me that "immutable distros" are seen as some radical thing instead of the way an OS is supposed to be
2025-12-12 07:13:56 <Ariadne> well i think immutable distros are good in theory, but not a 100% solution
2025-12-12 07:14:12 <idkrnx[m]> Ariadne: Isn't that the console like one?
2025-12-12 07:14:24 <Ariadne> it can be
2025-12-12 07:14:33 <Ariadne> they have a variant that just goes to KDE desktop
2025-12-12 07:14:36 <idkrnx[m]> Ariadne: I absolutely love the way atomic fedora and Android do updates
2025-12-12 07:14:38 <Ariadne> "client" OS is hard
2025-12-12 07:15:23 <idkrnx[m]> I don't think android updates have ever broken without f2fs errors
2025-12-12 07:15:58 <idkrnx[m]> It also makes signing the os much easier when you have a guaranteed base
2025-12-12 07:16:37 <idkrnx[m]> I hate the "Linux way" distros are
2025-12-12 07:16:56 <idkrnx[m]> Where there's no distinction between os and user
2025-12-12 07:17:06 <idkrnx[m]> And I'm not ever talking about security
2025-12-12 07:17:19 <idkrnx[m]> s/ever/even/
2025-12-12 07:19:02 <idkrnx[m]> And I hate how installing anything requires root
2025-12-12 07:20:50 <idkrnx[m]> There is absolutely no need for it and packages shouldn't expect to be able to make system changes during install
2025-12-12 07:21:02 <idkrnx[m]> Just let me install something for my user only
2025-12-12 07:21:37 <idkrnx[m]> Ok I'll take a break now
2025-12-12 08:35:08 <Sertonix[m]> <idkrnx[m]> "Where there's no distinction..." <- Ariadne: Is there a noticable difference to s6-sudo?
2025-12-12 09:58:58 <Ariadne> Sertonix[m]: afaik s6-sudo does not support interactive sessions, but the idea is similar
2025-12-12 10:00:25 <Ariadne> it is also intended to be consumed standalone with no dependencies outside libc
2025-12-12 10:42:36 <Ariadne> i have plans that are different than s6-sudo in the longer term (pre-opened FDs, that sort of thing)
2025-12-12 15:30:50 <Sertonix[m]> One thing I have been wondering about s6-sudo (and now capsudo) is if there is a simple way to not inhert the capability to a subprocess without uid/gid change or complex namespaces. Eg. when starting a browser from the terminal.
2025-12-12 20:22:29 <Ariadne> Sertonix[m]: that's something i want to look into with capsudo eventually: launching processes into isolated namespaces with pre-opened resources, etc
2025-12-12 20:26:12 <lonjil> heh, I posted the capsudo blog post somewhere, and that's one of the exact things I said you'd probably use capsudo for, when someone didn't get it
2025-12-13 12:14:35 <omni> c-ares in 3.20-stable is at 1.33.1, not sure if it should be upgraded or patched for CVE-2025-31498 & CVE-2025-62408 (both introduced in v1.32.3)