gchristensen changed the topic of #nixos-security to: Vulnerability Roundup Issues: https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+Vulnerability+roundup + https://broken.sh
justanotheruser has joined #nixos-security
colemickens_ has joined #nixos-security
justanotheruser has quit [Ping timeout: 250 seconds]
<pie_> related to yesterdays discussion on shellcheck, do you guys think nix substitutions should be quoted? i usually quote them but i heard there was a funtion in lib and i should probaby be using that
<pie_> s/probaly/definitely/ let wat = ''"lol"''; in ''"${wat}"''
<gchristensen> maybe so
<gchristensen> one thing is most of the time, the data being interpolated isn't "user input" and is pretty well controlled and understood
<pie_> ofc shellcheck wont cover that for us
<gchristensen> and the realm of failures is pretty well controlled
<pie_> ok so maybe its less of a security issue and more of a bugs issue
<gchristensen> the trouble is sometimes the variables *are* user input and it is obscured
<gchristensen> by being in a nix expr
<gchristensen> so I think it is still a good idea
<pie_> yeah so just escape everything properly
<pie_> i see no argument yet for why not to
<gchristensen> there is no real argument to not do it
<pie_> question is what to do about all the lib.someEscapeThingy clutter
<pie_> probably nothing for starters.../me scratches head
<pie_> sounds language extension prone
<pie_> and we arent ghc i guess :P
<pie_> do we have the log bot in here
<pie_> oh yeah nvm
<MichaelRaskin> I remember how the simplest way to test some configurations of Xorg with NixOS config generator is to perform code injection…
<pie_> is that xorgs fault or the config generators
<MichaelRaskin> Config generator's — «extra» options do not allow to add what I needed to add, so I just found an option that went to the end of a section, closed the section and injected another one
<pie_> heh, figuured something like that :I
<pie_> i tried to do something on the nix level once where i tried to override an unscoped baseNameOf, but im still not sure whether that would work or not
<pie_> s/would/could
<gchristensen> oh it could
<gchristensen> hehe
<pie_> nix is feeling increasingly fucked up since yesterday why do you people keep shattering my dreams :P
<gchristensen> we shattered them?
<pie_> "i thought nix is perfect" (jk)
<MichaelRaskin> I sinecerely think that NixOS has chosen wrong sides on multiple tradeoffs, that is not a problem of Nix per se!
<pie_> im just joking though
<MichaelRaskin> You can even easily write a Nix-based OS image and salvage the bits of NixOS you still want there. (I do)
<ekleog> MichaelRaskin++
<{^_^}> MichaelRaskin's karma got increased to 13
<ekleog> (though I still use NixOS, not having enough time to maintain my own stuff yet)
<pie_> so anyway...hella escaping problems
<pie_> profpatsch had some input <pie_> wait werent you suggesting having a bash EDSL in nix <Profpatsch> Nah, I’d use something like execline as a compilation target instead
Profpatsch has joined #nixos-security
<Profpatsch> To clarify: bash is a bad DSL in the context of generation of bash.
<Profpatsch> Because it’s made for manual, human input
<Profpatsch> So it has a few … interesting ideas that don’t make sense from an automation perspective.
<Profpatsch> Unix has that problematic conflation of human input and automation target everywhere, it’s a desease for efficient automation and security
<infinisil> MichaelRaskin: Ah so rfcs#42 addresses that problem?
<{^_^}> https://github.com/NixOS/rfcs/pull/42 (by Infinisil, 5 weeks ago, open): [RFC 0042] NixOS config options
<MichaelRaskin> I don't really think it addresses both sides — it doesn't say anything about escaping quality standard
<MichaelRaskin> Should make defining complicated custom configs simpler, though, yes
<pie_> Profpatsch, thanks for the clarification, that went over my head a bit
<infinisil> MichaelRaskin: Wait let's discuss in #nixos-dev, to not conflate this chan
sphalerite has quit [Quit: reboot time!]
sphalerite has joined #nixos-security
sphalerite has quit [Quit: WeeChat 2.2]
sphalerite has joined #nixos-security
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-security
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-security
justanotheruser has joined #nixos-security
justanotheruser has quit [Ping timeout: 258 seconds]
justanotheruser has joined #nixos-security
justan0theruser has joined #nixos-security
justanotheruser has quit [Ping timeout: 255 seconds]
justan0theruser is now known as justanotheruser
<andi-> uargh https://bugzilla.redhat.com/show_bug.cgi?id=1684610 "CVE-2019-3844 systemd: services with DynamicUser can get new privileges and create SGID binaries"
<andi-> we are getting a "honorable" mention in https://bugs.chromium.org/p/project-zero/issues/detail?id=1771
<pie_> so i think this justifies "paranoid distro configs" preventing one from using bind mounts @ Profpatsch @ earlier discussion ? " the following trick also needs to be mitigated, assuming that the distribution hasn't blocked the unprivileged creation of user namespaces:"
<pie_> re: use of being able to use something other than /nix as a store location as a nonroot user without bind mounts
<pie_> (although the issue *is* stated as low severity)
<pie_> andi-, also, yay, honorable mentions are a start :D
<pie_> idk much about systemd, can we do this "(And really, in general, it would be nice if NoNewPrivileges=yes could become
<pie_> the norm at some point.)"
<pie_> / should we? / leaving someone scratching their heads why something doesnt work
<andi-> Well I am going back to checking what the state of updating out systemd is.. that is something I did in Ocotber, abandoned, Mic92 picked it up again in February.. It is just two small changes according to the history in the PR..
<pie_> funnily enough we do seem to sometimes end up with some rather outdated core packages sometimes (?)
<pie_> though i dont know how other distros compare
<andi-> well we must maintain a systemd fork..
<pie_> its because the llamas are eating all the hands, gotta do something about carl.
<pie_> andi-, i didnt know we do that
<pie_> why?
<pie_> not why is it necessary, but what is it that we need?
<andi-> assumptions that arent true on nixos
<andi-> https://github.com/andir/systemd/commit/300073d3810c79c6beb3ac2854638b7a095b8e90 is a good example... is something that we might/must add in some form since there is no FHS
<pie_> oof This branch is 9347 commits behind systemd:master
<pie_> oh wait i assume this isnt the actual branch
<pie_> that is used
<pie_> gchristensen, has stuff changed much since you gave the nixcon talk about the vuln roundups
<pie_> i talked to one of the incident response guys at my company for his input and i got some, but i havent really distilled anything usable yet