<ekleog>
There's no setuid wrapper for xorg in nixos, and the patch appears to apply only to the argument parsing step (which is only possible to trigger by root on nixos), so I think we're safe
<ekleog>
Then, maybe there's a module that actually adds a setuid security wrapper for xorg?
<ekleog>
After check I can't find anything that looks like it'd do it by grepping for either security.wrappers, startx or xinit, so would guess we're safe from it and could just wait the next release
<timokau[m]1>
Great, thank you for looking into it :)
<pie_>
why /not/ apply it anyways?
<gchristensen>
we should, sure, it just changes priorities you know?
<pie_>
ah
<timokau[m]1>
Yeah if someone makes a PR I think there is no reason not to merge it since the patch comes straight from upstream itself.
* pie_
mumbles something about architecture for mitigation
<ekleog>
well, trying to make One Big Framework for all the things isn't really a great architecture for helping about security… like, systemd-journald runs as root, etc.
<ekleog>
now, yeah, it did bring many simplifications to using security tools provided by linux :)
<pie_>
maybe the big truth to deduce is systemd should have happened before systemd happened
<pie_>
what even happened there? did redhat just make a super agressive push to mainline it or what
<ekleog>
basically, yeah
<pie_>
and why did anyone let that happen
<pie_>
^i mean thats easy to say...
<ekleog>
because everyone was on sysvinit because no one moved to other things before, and sysvinit is way worse than systemd :p
<pie_>
meh.
<pie_>
idk i guess i just woke up angry today
<pie_>
because of the security stuff, and because of realizing yesterday that what i dont like about systemd so far is all the moving parts you need to have any chance of doing something
* pie_
goes to cool off
<pie_>
dont even know what im worked up about xD
<ekleog>
well, i don't like systemd either, but it's mostly because i love replacing parts of my system just about everywhere with other stuff, so having a big “one-size-fits-all” system isn't really my cup of tea :p
<pie_>
yep i was trying to say something about that
<pie_>
everything is monolithically depending on it
<pie_>
and its ad-hoc? so you cant really make alternatives
<ekleog>
otoh… well, it's also how linux works, and you can't really replace it :p
<ekleog>
now, long live micro-kernels!
<pie_>
^ probably
<pie_>
ekleog, well yeh it feels like it just cancered itself in
pie_ has quit [Ping timeout: 252 seconds]
pie_ has joined #nixos-security
<ekleog>
wtf have I done?
<ekleog>
was trying a potential privesc vuln on nix, and suddenly my whole i3wm crashed o.O
<ekleog>
that was *definitely* not supposed to happen
<gchristensen>
:o
<ekleog>
hmm so it only appears when trying to debug my poc in gdb outside of nix, nix's sandbox actually does contain it
<ekleog>
wow. I guess sudo -u nixbld1 -s to run the poc didn't please systemd… systemd[1]: user-runtime-dir@1000.service: Unit not needed anymore. Stopping.
<gchristensen>
oooh
<ekleog>
… and it doesn't reproduce, weird
<ekleog>
well, my poc does manage to crash gdb, though :D
<ekleog>
well, so my idea was likely nothing actually, sending an email with the idea anyway :)
<pie_>
gg :) :p
<andi->
ekleog: that sounds a bit scary.. Do you have a coredump/stack trace for gdb?
<andi->
There are many tools that try to spawn gdb when they get a sigsegfault..
<ekleog>
andi-: actually I think I understand my mistake: my program must have been kill()'ing gdb and, in the case of crashing the whole i3wm, I must have been kill'ing it
<ekleog>
and the trick is that I thought I was running it as nixbld1 but the first attempt must have killed my shell, thus falling me back to my regular user, I think