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
Synthetica has quit [Quit: Connection closed for inactivity]
Synthetica has joined #nixos-security
pie__ has quit [Ping timeout: 258 seconds]
justanotheruser has quit [Ping timeout: 258 seconds]
pie__ has joined #nixos-security
<pie__> andi-, someone i know: "So ANSSI just dropped some hot stuff here. They developed a graph database based, open source threat intelligence platform that will be released soon: https://www.opencti.io/en/ It looks amazing." its not actually released yet and no talks are recorded so im like....mehhhhhh :c ...but watch this space I guess
<andi-> pie__: kinda burned out on those.. Still have to write a few patches for MISP as part of my day job..
<pie__> meh
<pie__> i havent put much effort into it just some ambient thinking, and we'd only find some subset of the functionality useful probably, if anything
<pie__> current ponderance: supply chain attacks on nix again
<gchristensen> oh?
<pie__> gchristensen, i think youve been promoting usage of yubikeys right?
<gchristensen> for sure
<gchristensen> u2f for github auth is excellent
<pie__> i mean i dont feel like i have any good ideas, just thinking what it would take to compromise a commiter machine
<gchristensen> and it makes using GPG, indeed, less horrific
<pie__> im not so worried about that, but thats good to have too, get rid of low hanging fruit and whatnot
<pie__> or rather, im not thinking abot that
<gchristensen> right on
<pie__> im just thinking again about how i feel theres increasing prevalence of supply chain attacks or things that could be supply chain attacks, makes sense too imo
<pie__> and signing by itself wont help with that
<gchristensen> right
<pie__> that will get you attribution to a compromised target after the fact maybe, but will do nothing about preventing injection of stuff into the upstream
<pie__> a hardware module that doesnt allow exporting private keys will at least prevent compromise of the key, but between the commit <-> signing process there isnt anything preventing a malicious actor from mangling the thing youre requesting to be signed?
<gchristensen> that sounds like a complicated attack
<pie__> theres probably easier ways, its easy to think of hollywood movie plots to paraphrase schneier
<gchristensen> and the signature won't match
<pie__> i dont know how signing actually works exactly but you just change data at the point that would make it correct (?)
<gchristensen> MichaelRaskin likes to remind me that it would not be difficult to pay somebody to make good contributions to Nixpkgs for 6mo, get commit bit, and then go wild
<pie__> makes sense
<gchristensen> and that would be cheaper than hollywood :)
<pie__> but anyway im not sure anything could *theoretically* be done about this, because the primary function of a committer is to...ingest new code
<pie__> so im kind of stuck
<pie__> something something capability system to limit damage but...idk
<gchristensen> Nix already protects aganist many attacks by using its cap system
<gchristensen> youcould look at what Debian does to vet contributors and new contributions, pie__
<pie__> what do you mean?
<pie__> @ cap system
<pie__> yeah ive had comments about that so i guess i should
<gchristensen> building and installing software with Nix uses the principle of least authority
<gchristensen> installing software has no "hooks", so installing malicious software is not the dangerous action
<pie__> i dont *quite* follow
<gchristensen> building a Nix package is tightly sandboxed
<pie__> yeah
<gchristensen> it has no access or authority on your system
<pie__> yeah i got that
<gchristensen> ok
<gchristensen> makingc breakfast
<pie__> ok
<gchristensen> actually not sure where I was going with that
<pie__> ;p
<pie__> happens
<gchristensen> :)
<pie__> i guess im preoccupied with malicious code showing up unnoticed
* gchristensen is tired already
<pie__> we seem to have good integrity stuff for when something is already in the system
<pie__> but we are a very dispersed community, which is fine, but we need/want (?) technical solutions to problems that arent necesserily technical
<pie__> and for the problems that are too hard to solve technically i guess we have to solve otherwise
<pie__> when i mentioned capability system i was thinking more in the sense of the nix language, but i didnt think of anything concrete so maybe im just making word soup
<gchristensen> have you talked to simpson about nix's built-in capability system?
<pie__> ive brought this up a few times but never properly
<gchristensen> yeah
<gchristensen> simpson has a good perspective and understanding, worth seeking out a conversation specifically with him
<pie__> i mean im saying "woo capabilities" but i dont have any concrete thoughts yet on what we could actually preven
<pie__> also given the large disconnect between nix language evaluation level stuff and actual package runtime
<gchristensen> yes, simpson can help you understand exactly what we already do prevent with Nix's capabilities
<pie__> like, the nix runtime prevents you from making suid exes or whatever, but i dont see offhand how we could do anything from the nix language level - barring isolation of some kind of functionality to well controlled language construct
<pie__> ok
<pie__> well simpson should consider himself several times pinged :P
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-security
marek has joined #nixos-security
<ekleog> gchristensen: about the “pay someone to make good contributions during 6mo then go wild,” it's exactly what signatures would help protecting against (while they wouldn't help against a compromised committer) -- assuming we have a way to tie key ownership to real-world identity, of course
<pie__> i dont see how that necessarily helps
<ekleog> pie__: you can sue the person who did it
<pie__> well, unless said person has some reputation to uphold
<pie__> ah
<pie__> so what if its some random chinese person
<gchristensen> (that sounds a bit racist?)
<gchristensen> part of the game is definite "Cover Your Ass"
<ekleog> now, maybe justice would accept other circumstancial evidence as proof it's indeed the committer even without signed commits, but it's not guaranteed -- in the same way it's not guaranteed that it would accept the signature as proof
<gchristensen> anyway, this fits in to how Debian manages contriburs
<pie__> gchristensen, maybe - something something chinese APTs in the news all the time
<pie__> no not really racist
<pie__> i mean you get american APTs as well
<ekleog> gchristensen: I think pie__ meant random person living in china (or russia for that matter) -- countries known to not be really willing to follow suits
<pie__> apt being advanced persistent threat
<pie__> and so on
<pie__> but yeah + ekleog
<gchristensen> sure
<gchristensen> we can't resist an APT
<pie__> well, cant we?
<gchristensen> I'm going to say no
<gchristensen> (and, we do have Chinese contributors already)
<ekleog> we don't have enough manpower for the time being
<pie__> but yeah im inclined to agree gien that i dont see how we could avoid the fundamental premise of a committer being to ...commit code
<ekleog> when we have enough manpower to require 3 reviews per contribution we can start thinking about defending against state adversaries
<gchristensen> (and Russian contributors)
<pie__> i didnt mean to imply that i have anything inherently against chinese or russian contributors
<pie__> and at least we have human readable code for the most part
<gchristensen> right
<ekleog> for now defending against the 6mo contributor turning wild is a good first step imo
<gchristensen> I don't think it is useful to bring country of origin in to this discussion at all, so let's just not do that
<pie__> ekleog, sure. also why i was vaguely wondering about some vague notion of capabilities systems - decrease key load.
<gchristensen> part of "blue team" (protection) is resisting attack, but also part of blue team is mitigating a successful attack, and also protocol of dealing with the results
<pie__> yeah
<pie__> i wouldnt mind red team but i dont have any experience and how do you even red team an open source project
<gchristensen> all of these are important components, and we don't have to imagine APTs
<gchristensen> there are simple exercises we could do
<pie__> like, could contributors agree to being red teamed
<gchristensen> for example, commit a patch direct to master which adds "malicious commit!" to a file and see what happens
<pie__> who gets on the red team, scope etc etc - probably a mess logistically
<pie__> i mean i have no idea what im talking about
<gchristensen> yes, it would need to be coordinated with the NixOS Foundation
<pie__> i guess pentesting the infra would be feasible
<pie__> but *shrug*
<gchristensen> but, red teaming is not useful unless the organization has operational plans and expertise in place already
<pie__> makes sense i guess
<xorAxAx> hmm, i presume the "person commits compromised code" is less likely than "person commits faulty code" or "attacker does MITM on the wire to send compromised code"
<pie__> gchristensen, sidenote, if we have fully reproducible infrastructure setting up a test environment should be fine
<pie__> xorAxAx, signing would prevent the last part depending on what you mean by on the wire?
<pie__> unless something something commits from github UI
<xorAxAx> pie__, does git check the signatures of signed commits on fetch?
<gchristensen> no
<xorAxAx> pie__, (it would also require git support in nix-channels)
<pie__> xorAxAx, oh im not sure. i think some people enable that but it might not be enabled by default
<gchristensen> for further discussion on GPG there is an RFC
<pie__> i think we should get that enabled by default tho if its not a huuuge perf hit
<{^_^}> rfcs#34 (by lrvick, 31 weeks ago, closed): [RFC 0034] Expression Integrity
<pie__> sidenote on the whole above discussion: not that we probably dont have enough low hanging fruit anyway - and im bad at keeping my head out of the clouds
<xorAxAx> ah, that sounds interesting as well - it would probably mean that untrusted expression acquiration channels are still supported
<gchristensen> pie__: :)
<xorAxAx> ... and secure
<simpson> pie__: Nix builds require an explicit list of build inputs, and otherwise a build cannot get a hold of a particular package. This is like closely-holding capabilities; by closely-holding packages, Nix treats (references to) packages as capabilities.
<simpson> As an example, a cheap result would be that breaking out of the Nix buildtime sandbox requires a buildinput which has some special sandbox-breaking ability; that ability can't be forged arbitrarily while following the rules of Nix.
<pie__> ok yeah that much makes sense to me and i figured the functional-like paradigm would yield something like that. but can we actually in practice restrict the language?
<gchristensen> what about the language?
<pie__> i mean can we restrict what any given piece of code does
<pie__> i guess you are limited to what you can do in the sandbox and to your output directroy
<pie__> *directory
<pie__> im not sure what problem im trying to solve though
<pie__> (modules are probably more interesting)
<gchristensen> modules have much greater authority
<simpson> pie__: We already do. Pick (almost?) any default.nix in nixpkgs, and you can tell what it does by the arguments it takes at the top.
<pie__> simpson, you can run arbitrary bash code wherever with an override?
<simpson> Nix wasn't *designed* for this, so it's not a reliable indicator, but this is the sort of concept I'm trying to get across: We know *exactly* what is passed from one object to another.
<pie__> simpson, yeah that at least makes sense to me
<simpson> pie__: Aren't those bash snippets sandboxed, though?
<pie__> yeah theyre sandboxed (everything is sandboxed, hence why im not sure what im trying to solve)
<pie__> i guess the problem is if you somehow make a bad executable that the user then runs normally. but im not sure anything can be done about that
<simpson> Ah, sure; we don't have anything that prevents somebody from uploading malicious patches and then causing downstream users to be exploited.
<simpson> I mean, we have *people* and *social processes*, but to me those are sources of, not solutions to, the security problems you've outlined.
<pie__> i dont think we disagree?
<simpson> Sure. This isn't an agree/disagree conversation.
<simpson> If you want a head-in-the-clouds idea, imagine binaries that statically promise to only use a certain subset of the syscall API.
<pie__> sure
<pie__> sounds good
<pie__> actually /me ponders
<pie__> also something something apparmor etc
<simpson> But Nix is a transitional capability system, not a perfect encapsulation. We have basically no power over the final binaries, other than the power delegated to the user to choose which binaries are in a given scope.
<pie__> stop me if this is going off on a tangent but i guess the holy grail of an attack would be to get something into a base package
<simpson> Sure. Compromising GCC or Clang would be a big deal.
<pie__> maybe im approaching this the wrong way - lets say we have a malicious comitter. what can they do any what can we do about it
<pie__> in a damage minimization sense
<gchristensen> one possible damage mitigation route is require more reviewers the more packages impacted
<simpson> Like, we've identified that a particular commit is malicious? We can revert that commit. We can mark the affected build outputs as tainted, removing them from Hydra and announcing the problem to users.
<gchristensen> a compromised leaf package is uninteresting
<gchristensen> (not good, but not the worst)
<gchristensen> a compromised stdenv is much more interesting as an attacker
<pie__> simpson, or that i suppose it splits into two scenarios 1) smash and grab - ideally someone notices quickly 2) low and slow / not noticed
<pie__> well im mixing up strategy and noticing which are orthogonal, but eh
<pie__> no. i mean there is a malcious commit we havent identified
<pie__> gchristensen, right
<simpson> pie__: Sorry, I don't want to analyze panic-driven or fear-driven models. We should be precise: What exactly do we want to not have happen?
<pie__> simpson, yeah, <pie__> no. i mean there is a malcious commit we havent identified
<pie__> thats what i meant
<simpson> There's a bit of an elephant in the room: None of us have *ever* read GCC front-to-back, and so none of us can really show that there's not already a backdoor.
<gchristensen> hehe
<pie__> simpson, sure. im not against you telling me something like "the problem is fundamentally flawed"
<simpson> pie__: Then I think that we treat it like a CVE or other security vuln in a leaf package, with the additional remediation step of auditing the original committer.
<pie__> i havent been able to pin it down myself.
<pie__> i think my best summary was still "you have unnoticed Bad Things (malicious comitter / comitter with compromised machine /etc). what can you do about it?"
<pie__> emphasis on unnoticed because im interested in prevention
<pie__> not remediation
<simpson> pie__: Rely on the free capability theorems. If a user doesn't use the compromised package, then they're unaffected. If a user doesn't call the uncompromised package outside of build steps, then they are only affected for those particular built packages' outputs.
<pie__> (though being able to do the latter is of course still important)
<simpson> Think of the water balloon and the sponge. Both leak when stabbed by knives. The water balloon has no internal structure, so it fails completely; the sponge has internal structure which naturally (automatically!) resists leaking even when damaged.
<pie__> simpson, i think its a fair assumption that an "important" package is targeted, for some value of important, otherwise the scenario is pointless?
<pie__> like, some web server or whatever even, its not a core OS package
kgz has quit [Quit: WeeChat 2.3]
<simpson> pie__: RFC 34, which I'm still examining, suggests that leaf packages like Bitcoin wallet managers will be prime targets.
<gchristensen> pie__: have you read how Debian vets new packages and new contributors yec?
kragniz has joined #nixos-security
<pie__> gchristensen, no, guess i should up the priority on that?
kragniz is now known as kgz
<pie__> ive mostly been fighting with go2nix alld ay
<simpson> They are focused on attacks against the users' homedirs which exfiltrate data, and I think that the design of Nix prevents that without having the user actually run the targeted leaf package.
<gchristensen> pie__: this conversation would be more profitable if we continue it after you read it
<gchristensen> simpson: bitcoin wallet managers are doing a good job of being vulnerable on their own without needing to target a package manager ;)
<pie__> heh^
<pie__> i mean i really havent said what "a malicious commit" means. i guess as we touched on, there isnt anything that could be done from the nix side to prevent run time (patched) malicious code problems.
<pie__> other than using runtime capabilities - selinux, apparmor?
<gchristensen> in the NixOS case, that would help yeah
<pie__> maybe using nix could make managing that a lot better though?
<pie__> theres probably been discussions on this but i havent thought / remembered to look at them
<gchristensen> an important thing is Nix doesn't _have_ a runtime. it evaporates at the end
<pie__> gchristensen, sorry by runtime i mean running a program
<gchristensen> right
<gchristensen> I know
<pie__> ok i dont follow
<gchristensen> if Nix had a runtime (like Docker) then it could do some magic around enforcement, but Nix is out of the picture at the program's runtime
<pie__> ah. thats fine i think?
<pie__> this space should be covered by the kernel?
<gchristensen> well it is a trade-off. I happen to think the right one
<gchristensen> Nix could provide tools for to easily reduce the executable's privileges
<pie__> hm - or rather, ideally anything except the very base enforcement code would be outside the kernel
<simpson> gchristensen, pie__: Did anybody actually post the DD checklist? https://www.debian.org/devel/join/nm-checklist
<gchristensen> thanks, simpson
<pie__> ok i added redaing the debian vetting and apparmor/selinux/capsicum/etc to my todo
<pie__> simpson, thanks
<pie__> was there a third thing?
<pie__> *ok i added reading
<gchristensen> firejail
<pie__> we didnt talk about that, but maybe there wasnt a third thing, but ok ill check out firejail too (ive heard of it)
<pie__> (also anything else is fine, i just thought i forgot something
<gchristensen> ah, I was alluding to it at 14:55 <gchristensen> Nix could provide tools for to easily reduce the executable's privileges
<simpson> Reminds me of applying to university. A portfolio, some identification and vouching from prior graduates, and an essay on why you'd be good for the university.
<pie__> a question is how not to wreck usability for normal users, but thats probably discussed plenty elsewhere
<ekleog> firejail has the design issue that it requires to elevate privileges in order to drop them
<gchristensen> hehe true
<pie__> ekleog, ironic
<ekleog> if someone wants to make a GUI for https://github.com/Ekleog/toboggan/ , it's all that's missing for it to be able to replace firejail without this privilege escalation :p
<ekleog> (2 years ago already… :( )
<ekleog> based on seccomp + ptrace to filter syscalls
<pie__> (tell me when Qtah (an acquaintances WIP haskell qt binding) is finally usable :P)
<ekleog> and/or the Mbox I linked in the readme when I gave up on writing the UI because I'm bad at finishing stuff
<pie__> ok so if we have runtime capabilities that could (?) reduce cross-package damage
<pie__> so you wont get so pwned by some random app you download unless its the kind of thing that fundamentally requires system acces
<pie__> *full system/etc
<simpson> pie__: Sure. But that is the realm of CloudABI, Capsicum, and other rewrite-required solutions. In fact, it's *expected* that taking advantage of capabilities means rewriting code.
<pie__> hm
<simpson> (It's very curious to hear phrases like "how not to wreck usability for normal users" given that Nix, as a capability system, *intentionally wrecks the 'normal user' experience*.)
<pie__> just because nix is hard to use now doesnt mean it has to be later
<simpson> Not hard, but *different*. Requiring rewrites, requiring UX changes.
<pie__> simpson, im not sure what you scoped "rewrite required" to re: capsicum
<globin> pie__: you might be interested in the SELinux RFC
<pie__> i dont know anything about this stuff but you could for example just hide files you dont have capabilities for, for example, as opposed to needing to rewrite the api? i imagine this is what selinux and the like might do since i dont think i saw anything about selinux causing a rewrite and its kernel side
<pie__> globin, ah, makes sense then. ill definitely check that out
<pie__> i guess this all fundamentally is coming down to compartmentalization.
<pie__> that makes some sense, if you have a malicious actor whos behaviour fundamentally intersects with what they are supposed to be doing anyway
<simpson> pie__: Sorry, I don't know how to get this across the language barrier, but you need to turn your thinking inside-out here. In a capability-aware world, any object (including user agents!) can do exactly what it currently has the ability to do. Nothing more or less. http://habitatchronicles.com/2017/05/what-are-capabilities/ might help.
<pie__> simpson, thats what i expected? my model is "here is a bag of functions, you can call them."
<pie__> "you cant construct your own functions, etc etc"
<pie__> thanks for link
MichaelRaskin has joined #nixos-security
pie__ has quit [Ping timeout: 268 seconds]
pie__ has joined #nixos-security
Synthetica has quit [Quit: Connection closed for inactivity]
justanotheruser has joined #nixos-security