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
<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
<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]