05:17 <cruxbot> [contrib.git/3.6]: nginx: updated to version 1.21.6

17:11 <cruxbot> [opt.git/3.6]: iwd: update to 1.22

17:11 <cruxbot> [opt.git/3.6]: geeqie: update to 1.7.2

17:11 <cruxbot> [opt.git/3.6]: glib: update to 2.70.3

17:12 <cruxbot> [core.git/3.6]: libcap: update to 2.63

18:19 <cu_LA> hello

18:54 <dlcusa> Re: CVE-2021-4034, I downloaded https://haxx.in/files/blasty-vs-pkexec.c which seems straight-forward, ran gcc -o blasty blasty-vs-pkexec.c successfully, and running ./blasty logged a suspicious invocation, so it appears CRUX is immune.

18:57 <tilman> better safe than sorry and remove setuid from /usr/bin/pkexec ;)

19:01 <frinnst> patch was added yesterday

19:03 <frinnst> https://crux.nu/gitweb/?p=ports/opt.git;a=commitdiff;h=f3a7b1c13b5d48e39691683f0c1070ce9b3d0faf

19:06 <dlcusa> frinnst, yes, but it's nice prepatch it still fails. Devuan, oth...

19:17 <pedja> fedora 35 still isn't patched, appaently

19:18 <pedja> according to comments in lwn thread, at least

19:31 <dlcusa> After maintenance and rebooting, Devuan's blasty only prints pkexec help, but the bits for pkexec are 4755/-rwsr-xr-x so I wonder how fixed Devuan is.

19:44 <pedja> Debian is patched. or did they diverge that much from it they can't import/reuse the bugfix?

19:53 <tilman> dlcusa: i'm not sure how reliable that exploit/demo is. .oO(why would unpatched polkit not be vulnerable on crux?)

19:55 <dlcusa> tilman, I expect a properly configured polkit should prevent the exploit, but I haven't found the time to dig into it.

19:56 <dlcusa> I think we all agree the setuid approach is contraindicated, however.

19:59 <cruxbot> [opt.git/3.6]: thunderbird-bin: updated to version 91.5.1

20:00 <stenur> me not. you can send a dbus message to a super-potent executable which does the work however

20:01 <dlcusa> We hold these truths to be self-evident: polkit is not KISS, etc.

20:06 <tilman> well, removing setuid breaks intended functionality

20:06 <dlcusa> Yes--this is a functionality design issue.

20:07 <stenur> i am with OpenBSD's de Raadt here, you must design sandboxing from the very start.

20:07 <stenur> And the attack vector of rised privileges should be as small as possible.

20:08 <stenur> And if that does not work you need to split up the program in two or even more, that are driven by the "superserver".

20:08 <stenur> Most "good" software does it like that anyway, may it be postfix, openssh, you name it. Right?

20:09 <stenur> Most OpenBSD servers now even have no longer the possibility to access the filesystem or do anything such.

20:10 <stenur> They start up, load certificates and keys and whatever, and then they fork(2) away, having lost their privileges and are locked somewhere in the filesystem.

20:11 <stenur> They added in-memory passing to ressl or more correctly their tls library whatever its name was, only for that, if i recall correctly.

20:11 <stenur> .. and if you need to communicate, they have special CMSG messages to communicate in between the high and the low privilege side.

20:11 <stenur> ... as i understand it.

20:12 <stenur> Then again, the programming error is pretty ridiculous :)

20:12 <dlcusa> Security has always been hard to design and this exploit reminds us what the risks are.

20:12 <stenur> Shit happens of course.

20:13 <stenur> That is why i always say the less software there is the better it is.

20:15 <stenur> Too few eyes with too few time for code audits, no no, rapid progression there has to be.

20:16 <dlcusa> Another self-evident truth: small attack surfaces are more desirable than large attack surfaces.

20:18 <stenur> Parsing command line options is a hard task for a C programmer, i see people screaming for JAVA Rust C# you name everything with collection objects not hard-memory C arrays.

20:19 <stenur> (That was humour almost Brit black. Of course.)

20:29 <pedja> that was programmer's humor, right? no wonder I can't tell what the punch line is :)

20:30 <stenur> The one bug (at the moment there float multiple vulnerabilities) was that the command line option argument vector is modified at an invalid position.

20:31 <stenur> Iirc .. actually i have not really looked in depth.

20:32 <stenur> (I am in total favour of service boxing or even VMization.)

20:32 <pedja> this https://github.com/ly4k/PwnKit/blob/main/PwnKit.c might as well be written in Linear A

20:36 <stenur> The polkit patch contains the words: If 'pkexec' is called THIS wrong, someone's probably evil-doing. Don't be nice, just bail out.

20:36 <stenur> Now this is a really young man. Right, dlcusa?

20:37 <stenur> https://crux.nu/gitweb/?p=ports/opt.git;a=commitdiff;h=f3a7b1c13b5d48e39691683f0c1070ce9b3d0faf

20:41 <pedja> I am guessing kernel patch discussed at https://lwn.net/ml/linux-kernel/20220126043947.10058-1-ariadne@dereferenced.org/ would prevent similar class of problems?

20:44 <stenur> Seems so (that patch)

20:49 <stenur> P.S.: i just see a FreeBSD commit: "execve: disallow argc == 0"

20:49 <stenur> https://cgit.FreeBSD.org/src/commit/?id=773fa8cd136a5775241c3e3a70f1997633ebeedf

20:50 <stenur> So that "FreeBSD and OpenBSD have it" mentioned in the linked message is fresh and hot

20:51 <stenur> But the manual page always said so: "Historically we allowed argc == 0, while execve(2) claimed we didn't."

21:13 <farkuhar> stenur "in total favour of service boxing" ... I just saw the weirdest behaviour, where clicking the "play" button on the embedded video in a qutebrowser window actually started the playback from the backgrounded mpd service. These programs should not have been able to pass messages to each other!

21:16 <dlcusa> farkuhar, misconfiguration? I really must look into Qubes some day.

21:17 <farkuhar> Well to be fair, mpd is configured to listen on a dedicated port, accessible without password to the entire LAN, but I can't see any reason for qutebrowser to be sending requests to that port.

21:18 <dlcusa> If folks like us can't ensure secure infrastructure for ourselves (lack of time to vet code), what hope have the lusers?

21:23 <dlcusa> stenur, I thought the comment quite wise. Enough to raise the right eyebrows, inoculous enough not to trigger unhelpful alarms for anyone in management that actually want the hole to be there.

21:25 <pedja> which management would that be?

21:26 <dlcusa> Not sure, but any that receive national security communications from their local powers that be.

21:27 <pedja> that code comment, as someone mentioned, is wrt the behaviour that it's only ever used for shell code, and has no legit use

21:30 <dlcusa> I must be elsewhere now indefinitely--enjoy the discussion.

21:32 <pedja> it's funny how the reaction to polkit's devs question "should we keep mozjs as an option, now that we switched to duktape as js engine?" was pretty unanimous "hell no" :)