<gchristensen>
has anyone implemented basic cryptography in nix?
<gchristensen>
you know I'm in for a good time here
<l33[m]>
interesting...
<gchristensen>
repulsive is more like it :)
<l33[m]>
I hear ROT13 is very strong.
<gchristensen>
I'm probably overthinkng it. I want to represent authority to access to the filesystem in the derivation, and prove the authority was granted from the overall system
<gchristensen>
I guess I could do it by examining the .drv graph of /run/current-system contains the drvs for the program and its granted authority
<gchristensen>
perhaps better than trying to do other cryptography
<l33[m]>
is this to stop users/programms executing stuff from /nix/store/dangerous.bin, that's not linked into their path or current enviroment?
<gchristensen>
that, and also modeling access to stateful directories too
<gchristensen>
like ... (withStatefulHome "firefox" "${pkgs.mozilla}/bin/firefox") would attach metadata to Firefox which lets it access a stateful directory for its storage
<gchristensen>
I need to experiment I think
<gchristensen>
I want to completely isolate programs started in my interactive GUI by default, and then add opt-in statefulness, and filesystem access authority
<gchristensen>
the problem is I don't want them to be forgeable
<l33[m]>
i presume normal unix user/group permission wont do?
<gchristensen>
mmmnot exactly, I want them all to be owned by me but I want the files and data to only be visible id they have a provable authority to access it
<gchristensen>
this is all pretty undefined in my head still
<infinisil>
So you want something that can say "Only this one script I built with Nix should be able to access this path"
<infinisil>
This kind of feels like something SELinux should be able to do
<infinisil>
Somewhat
<gchristensen>
yeah, but a bit more: built with nix and that nix build is part of the /run/current-system
<gchristensen>
is the*
<l33[m]>
SELinux can render you machine secure against all know threats, by rendering it inoperable.
<gchristensen>
lol
<infinisil>
hah
<infinisil>
gchristensen: I guess you'd make per-app-homes (iirc) chmod -x, such that you can't list files in it anymore
<gchristensen>
yea
<gchristensen>
and since only sway launches programs as me I can enforce the limitations are uniformly enforced there
<gchristensen>
(this is how I uniformly launch programs in their own cgroup already)
<infinisil>
I feel like simpson would have some opinions on this. I feel like capability theory would allow an elegant solution
<gchristensen>
exactly :)
<infinisil>
Like, by you running `nixos-rebuild switch`, you pass nixos-rebuild the capability to access firefox-<hash>, which is passed to the script it creates so it can do that
<infinisil>
(that's at least how I imagine it working)
<gchristensen>
pretty much, yaeh!
<l33[m]>
if i'm following this right... then rather encryption, you say has your file your path /home/nsa/firefox... and get a hash so /home/nsa/firefox/<hash> , however anyone can work that out, by hashing that path ... however, if you hash it with a salt, then only you know what the results is, at devivation build time, you would somehow inject this SALT into the build, thus the derivation can find out where you unique path is?
<infinisil>
Problem is that all of the /nix/store is world-readable, including all derivations
<infinisil>
So really, the problem has to be solved outside of Nix (or at least outside of the /nix/store)
<gchristensen>
and easy to write to :)
<l33[m]>
maybe you don't have to store the salt in the build at all.
simpson has joined #nix-lang
<infinisil>
Then you need to somehow pass the salt to that script
<infinisil>
And if you run the script as your own user, that means storing the salt somewhere where your user can access it, meaning any program running as that user can access it too
<gchristensen>
or verify an external property, like that the authority is granted by the top level symlink for the current system
<infinisil>
I think the fundamental problem is that the script you want to run needs an identity, so that whenever it needs to access the path, it can prove that it's itself
<gchristensen>
yea
<infinisil>
So, maybe the script itself needs a private key
<gchristensen>
and we hop right in to code signing
<infinisil>
And the path is encrypted with the public key
<l33[m]>
ouch!
<l33[m]>
maybe store the salt in a ssh-agent?? there must be somewhere where it doesn't get sucked into the store.
* infinisil
feels like hashing with a salt is the wrong thing to use here but isn't sure why
<l33[m]>
* same
<l33[m]>
Perhaps i mis understand the problem. But if the script you running , can't access the path you gave it (which is hashed , with a SALT you pass it), then it won't run.
<l33[m]>
but the problem might be more subtle than that.
<infinisil>
Not sure what you mean tbh
<infinisil>
gchristensen: But also. Even if somehow only that script could access that path, you need to ensure that only you can call that script
<infinisil>
Feels like capability theory again
<gchristensen>
it is entirely capability :)
<infinisil>
Is there an OS built with security based on capability theory?
<gchristensen>
I'm already only mounting /nix/store paths in the closure, so that should be okay
<gchristensen>
I think fuschia
<l33[m]>
as i see, you want to run something out the /nix/store/myapp.bin, so it's 777 currently, so any can. but if it will run if can access something unique in your home area?
<simpson>
Also Genode and seL4. Historically, also KeyKOS.
ris has quit [Ping timeout: 264 seconds]
<infinisil>
Neat
<infinisil>
I guess this kind of thing needs to be done on an OS level to get the full benefits of it
<gchristensen>
yea
<gchristensen>
to clarify, the main thing is the launcher which starts my guis. each of those should have their own isolated area. a special one of those is the terminal, which has few limits, but I'd like to be able to do one-off launches with persistent homes too
<gchristensen>
...from within the terminal
<gchristensen>
or auto-drop capabilities when I, say, enter a source code repository's directory before I run make
<gchristensen>
but these are pretty far off ideas and for now I want firefox to have its own home :P
<infinisil>
Hm, what if you make your terminal run with a different user with more privileges
<infinisil>
And you make firefox's path be owned by that user
<gchristensen>
I could but I do want to go about this in a capability model
<infinisil>
I don't think that's gonna happen in Linux!
<gchristensen>
nixschia when
<simpson>
I would pay attention to what ehmry's working on, with Genode and Nix together. I don't understand any of it yet though.
<gchristensen>
I am also hoping simpson will get back to me on ideas
<gchristensen>
when possible
<simpson>
I used to think it was intractable, on Linux. But maybe I am a pessimist.
<l33[m]>
you can't be a pessimist, if you use linux, because the fact that its working means by default your are an optomist.
<gchristensen>
simpson: my initial question is intractable?
<simpson>
That's how I felt about it years ago, at least. I'm probably out of date. The main question is how filesystem paths will become unguessable outside of the normal access mechanisms.
<infinisil>
Hm I think I had this discussion with gchristensen before, about somehow using fuse to give only certain processes access to paths
<gchristensen>
simpson: /home/grahamc/per-app-foos just won't be accessible within
<gchristensen>
once I launch sway no other program will be able to launch which gets access to /home/grahamc/per-app-foos
<gchristensen>
ehhhhh
<gchristensen>
unless they have systemd-run in their closure :)
<gchristensen>
or dbus in general. it won't be perfect, but it'd be somethingish
<infinisil>
Sounds janky!
<gchristensen>
:D
<simpson>
Sounds like an incremental improvement.
<infinisil>
I really hope that in like 30 or something years we'll all be laughing about how we used a non-capability-based OS at the time
<gchristensen>
btw simpson I have some unplanned vacation coming up, do you have any papers or whatever I should be reading?
<infinisil>
Hehe
<simpson>
Not particularly. I'm going to have to do some research in order to take your question seriously.
<gchristensen>
I mean more, uh, in general
<gchristensen>
a thread to start pulling on to learn more about capabilities and authority beyond what I've picked up just being around.
andi- has quit [Remote host closed the connection]
andi- has joined #nix-lang
jeanete701 has quit [Ping timeout: 272 seconds]
elvishjerricco has quit [Ping timeout: 244 seconds]
srhb has quit [Ping timeout: 260 seconds]
manveru has quit [Ping timeout: 268 seconds]
davidtwco has quit [Ping timeout: 264 seconds]
angerman has quit [Ping timeout: 244 seconds]
jared-w has quit [Ping timeout: 272 seconds]
mpickering has quit [Ping timeout: 268 seconds]
davidtwco has joined #nix-lang
jared-w has joined #nix-lang
angerman has joined #nix-lang
elvishjerricco has joined #nix-lang
srhb has joined #nix-lang
manveru has joined #nix-lang
mpickering has joined #nix-lang
angerman has quit [Ping timeout: 272 seconds]
angerman has joined #nix-lang
<MichaelRaskin>
I mean, I get like half of this today with nsjail, I think
<MichaelRaskin>
But I do not want global D-Bus, for example
<MichaelRaskin>
(I need to choose accessible paths on launch, though)
<MichaelRaskin>
Will need to run one more socket between inside and outside to re-sandbox invoked tools
ris has joined #nix-lang
<simpson>
At some point, maybe something like CloudABI or Capsicum is looking at, to give structure to that sort of isolation.
__monty__ has joined #nix-lang
<siraben>
Is anyone still working on a type system for Nix? https://github.com/regnat/ptyx hasn't seem to have had activity since 2018.
<__monty__>
I think the closest thing rn is Nickel?
<siraben>
Does that produce Nix code?
<siraben>
Is the idea to replace Nix entirely with a different language?
<siraben>
And you?
<siraben>
Oops wrong window
<__monty__>
I think Nickel's intended to become a superset of nix.
<__monty__>
Not sure if the syntax is/would be identical.
<__monty__>
If you want a *right now* solution there's always the dhall integration : )
jeanete70 has joined #nix-lang
<ehmry>
i wish cloudABI would happen, but I think getting actual security and isolation done right is something that can only be reasonably be done at system composition, which is what we seem to do best
<simpson>
ehmry: I am very much interested in advice that you might have for us.
<ehmry>
simpson: I wish I had advice but I am also confused about what to do
<MichaelRaskin>
All remote/separated desktop solutions right now are kind of meh, otherwise Linux containers are almost enough conceptually…
<simpson>
ehmry: Was it you that I'd talked with, about possibly putting NixOS into a Nix-managed seL4 arrangement? The idea would be that one could contact the seL4 kernel as a sort of hypervisor and request that various things run alongside Linux.
<ehmry>
maybe, but sel4 is a crap hypervisor that crashes lot
<siraben>
__monty__: What do you mean by dhall integration?
<ehmry>
simpson: but yes, that is possible
<simpson>
ehmry: I'm not up at all on Genode; is there an alternative route? When talking to you and dash before, it's sounded like I'm going to have to dedicate some specific hardware to running just Genode if I want to ever make progress there... I'd hope for something more incremental.
<MichaelRaskin>
simpson: I guess if you are willing to trust KVM + CrosVM you could have some incrementality
<MichaelRaskin>
(I am still on the step of using nsjail as much much better than nothing)
<ehmry>
simpson: genode has some virtio drivers now, so I've been playing with those. I can either focus on doing VMs or doing hypervisors but its hard to focus on both
<siraben>
__monty__: Ah I see.
<simpson>
No worries. I've mostly been focused on failing, so I'm interested in any non-failing paths forward.
niksnut has joined #nix-lang
<ehmry>
simpson: yea, if you make lots of work for yourself its hard not to feel that way
<simpson>
...That's quite fair. I didn't have to go to the moon for cheese; I could have just gone to the local grocer.
<simpson>
I think that the tremendous success of Nix is directly due to the transitional and incremental nature of how it enforces capabilities; it takes every free opportunity, but not much more.
<ehmry>
yea, and unfortunately for packaging worse is better, we have to optimize for packaing the wonky software rather than the ideal stuff
<ehmry>
I think nix is good at doing the practical thing
<gchristensen>
I love love love that in this context nix is the bad but practical option
<ehmry>
I wouldn't say its bad, patching binaries is bad if but if what you want runs now its good
<simpson>
Nix is immoral, which is kind of like "bad", in that it cannot perfectly enforce a package-capability discipline. But that's very much because e.g. Linux can't help us much with that.
<simpson>
(Or *can* it? Which is what leads to VMs w/hypervisors, containers, etc.)
<simpson>
n the capability-security world, we have the idea of "taming"; a tamed package is one whose behaviors are specifed and enumerated. One of the big difficulties has been coming to understand that taming is, in general, *impossible*; we have to work a lot in order to get anywhere. Nix's taming is pretty good!
<ehmry>
when I say worse is better I mean its good that we just make the appimage work rather that try to rebuild it from source
* ehmry
doesn't know where he is going with this
<ehmry>
I do wonder if in the future it would make sense to merge configuration functions with the packages themselves, but putting runtime requirements in there would also be interesting
<MichaelRaskin>
I guess if we had «Nix build sandbox except…» fine grained enough for shell.nix-like use, we could get better boundary-drawing
<MichaelRaskin>
(note that here isolation, user setup instructions and better test promise come together, they all need the answer to «so what the package needs at runtime»)