justanotheruser has quit [Ping timeout: 245 seconds]
drakonis has quit [Ping timeout: 240 seconds]
ris has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
<bgamari_>
is it just me or is buildGoModule completely broken?
<bgamari_>
it looks like the dependencies aren't actually fetched
<bgamari_>
e.g. Fetching file:///nix/store/npxv14jzh83n8yxw4lpi9hdwl7h88d53-gitlab-shell-go-go-modules/github.com/mattn/go-shellwords/@v/v0.0.0-20190425161501-2444a32a19f4.info
<bgamari_>
go: github.com/mattn/go-shellwords@v0.0.0-20190425161501-2444a32a19f4: open /nix/store/npxv14jzh83n8yxw4lpi9hdwl7h88d53-gitlab-shell-go-go-modules/github.com/mattn/go-shellwords/@v/v0.0.0-20190425161501-2444a32a19f4.info: no such file or directory
<bgamari_>
/nix/store/npxv14jzh83n8yxw4lpi9hdwl7h88d53-gitlab-shell-go-go-modules was created but is completely empty
justanotheruser has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
<eyJhb>
tazjin: but that would require all new services that comes in PRs to have stricter requirements, right? Because having sane defaults in the form of isolation seems like it would be quite difficult
<tazjin>
Yes, probably
<tazjin>
I'm not sure if there are quick wins available by changing something basic in the systemd module
<etu>
But it would be nice...
<tazjin>
DynamicUser might work across everything?
<tazjin>
As for patches, what if we had a global hardening toggle that people can gate extra isolation (per service) behind?
<eyJhb>
Thinking dynamicuser might work as well yes, and I seem to remember someone was working on something, regarding what sounds like could be used for this. - But it very much depends on the application most of the time, e.g. chroot and where it needs to write..
<eyJhb>
What would such a global hardening toggle do? Also, it would be something like.. systemd.services.<name>.harden = true;?
<tazjin>
One level up I think (hence global)
<tazjin>
it would enable all secure defaults we can get (such as dynamic users) on all services and let service modules gate specific more secure config behind it
<tazjin>
so users can opt-in and deal with any potential breakage then
danderson has joined #nixos-dev
<eyJhb>
Got confused by "per service", but that might work. Could be opt-in to begin with, and after a safe amount of testing it might be able to be default. - Would this calify for a RFC, or just a PR?
<tazjin>
RFC I think
<tazjin>
To determine which options we are even talking about
<eyJhb>
Just spitballing here, but maybe a approach could also be taken, to put everything into containers? But that would require quite some work...
<eyJhb>
Also because nixos containers are currently somewhat funky
<tazjin>
danderson pointed out that we'd need to consider things such as runtime state access if dynamic users are enabled, systemd can handle that via state directories - the question is what percentage of services defaults to a sane state location
<eyJhb>
Testing that would be quite difficult
<danderson>
hi! So, the reason I wished for this on twitter is that I'm currently putting everything in nixos containers, and it's a bit clunky :)
<eyJhb>
Or, it somewhat would
<eyJhb>
danderson: containers ?
<tazjin>
danderson: somewhat orthogonal to this discussion, are you aware of #spectrum?
<fpletz>
tazjin: I agree that this would be awesome but I can guarantee you that this would break nearly every service so it's a labour-intensive process because every service needs manual testing
<danderson>
tazjin: I am now!
<fpletz>
also note that there are still weird systems bugs with dynamicuser in containers with userns enabled
<fpletz>
*systemd
<danderson>
maybe I'm just more paranoid than average. My threat model is simply that I assume my network services will have an RCE vulnerability at some point, so I want as much sandboxing as systemd can offer without breaking the daemon
<eyJhb>
There are more stuff in containers that works funky as well, e.g. bindMounts
<{^_^}>
systemd/systemd#13622 (by globin, 1 day ago, open): systemd-nspawn -U is incompatible with RuntimeDirectory and DynamicUser
<danderson>
some of it (drop most capabilities, prevent re-acquiring them) should work pretty universally (except for daemons that need the privs, of course). Others (like chroots with dynamic users) will take more tweaking to work right
<eyJhb>
danderson: maybe, I am as well, but sometimes you give up on it
johanot has joined #nixos-dev
<eyJhb>
Yeah danderson, but how would you determine if the service work correctly when you drop capabilities?
<danderson>
I'm definitely not suggesting turning it on universally for everything at once. My question was more: if I start sending patches to tighten up security on stuff, is that welcome, or not a design goal?
<eyJhb>
Without manually testing :/
<globin>
it is very much welcome
<fpletz>
danderson: that would be very welcome!
<danderson>
there's a baseline you can comfortably apply, which is seccomp rules that match Docker's default seccomp profile
<danderson>
that's pretty much just "disable obsolete/dangerous syscalls", to reduce the kernel 0day surface
<eyJhb>
I still like tazjin idea, of having some switches that could be enabled, to ease maintaince. If we can have security rules across systemd services, that would be awesome
<danderson>
when they added the profile to docker, they did a lot of testing on a lot of software, and concluded that it all works fine :)
<eyJhb>
danderson: docker sane defaults still screws up some stuff, but I might also be doing weird stuff in my containers....
<danderson>
so, my worry with adding switches is that it's yet-another orthogonal switch that changes all derivations, unless I'm not understanding?
<eyJhb>
tazjin said to take it up a step, I suggest it for each service
<tazjin>
it changes the module configurations, not necessarily the service derivations
<danderson>
in the absence of automated testing, the next best thing is having enough people using the settings to quickly detect when it breaks
<tazjin>
so you'd have a `services.defaultHardening = true;` or something which flips on dynamic users, state dirs and other stuff automatically for all services
<danderson>
(well, IMO anyway)
<danderson>
oh, hmm
<danderson>
I think that would break a lot of stuff. But I'd have to think about it.
<tazjin>
(it'd be useful to determine all options which are relevant here)
<tazjin>
yes, that's the expectation
<tazjin>
thus, gate it behind a toggle
<danderson>
so the idea is, harden everything by default, but allow each service to replace with its own configuration, or?
<tazjin>
hmm, I guess you could just go and flip it on across all services even without this toggle and see what happens
<tazjin>
yes
<tazjin>
also, I'll be afk for a bit
<danderson>
I see. I worry that the result would just be "congrats, system is borked". But that might be useful for testing :)
johanot has quit [Quit: WeeChat 2.4]
<danderson>
I have to head to sleep now. Thanks for the discussion! I'll check back in tomorrow.
<eyJhb>
10 AM, wish it was me...
<eyJhb>
But wouldn't it somewhat make more sense, instaed of just having a global switch? Then each service/PR could specify what it needs to funciton, instead of a global state? - Or a combination of both
johanot has joined #nixos-dev
johanot has quit [Client Quit]
<eyJhb>
Wouldn't it actually somewhat be easier to put into containers?
johanot has joined #nixos-dev
johanot has quit [Client Quit]
johanot has joined #nixos-dev
johanot has quit [Quit: WeeChat 2.4]
johanot has joined #nixos-dev
johanot has quit [Client Quit]
FRidh has joined #nixos-dev
johanot has joined #nixos-dev
johanot has quit [Client Quit]
johanot has joined #nixos-dev
__monty__ has joined #nixos-dev
__Sander__ has joined #nixos-dev
ivan has quit [Remote host closed the connection]
allan has quit [Ping timeout: 245 seconds]
ivan has joined #nixos-dev
allan has joined #nixos-dev
delroth has quit [Ping timeout: 245 seconds]
ashkitten has quit [Ping timeout: 245 seconds]
tv has quit [Ping timeout: 245 seconds]
ashkitten has joined #nixos-dev
delroth has joined #nixos-dev
FRidh has quit [Ping timeout: 265 seconds]
tv has joined #nixos-dev
FRidh has joined #nixos-dev
<delroth>
I think it would be nice by starting to have a policy on whether we want to have these hardening options in nixos systemd service configs
<delroth>
I have a few custom patches in my nixpkgs fork that I didn't bother upstreaming because 1. it's like 10 lines of systemd config cruft per service for something relatively few people care about; 2. it's hard to test in every single scenario, I can vouch that it works for my use case but not in all use cases
<delroth>
maybe one path we could go with is 1. provide a "systemd.services.xxx.harden = true;" switch which sets mkDefault values for all these hardening options (with the most hardened as default); 2a. let users set harden=true in their nixos configuration to figure out what breaks and relax those settings; 2b. have the hardened profile set harden=true on some chosen daemons; 3. upstream the settings
<delroth>
that need to be relaxed and set harden=true by default on those services
<delroth>
there are many issues with that though: for one, it's long manual work that isn't future-proof, i.e. we can't really turn on new hardening options automatically without fear of breaking things
* emily
would love to have things like this upstream
<emily>
behind an option seems reasonable, though it's not like NixOS doesn't randomly break features of software anyway >_>
niksnut has joined #nixos-dev
<fpletz>
delroth: thanks, your last point is the reason why I would advise not to add a harden convenience option but do it on a per service basis
<fpletz>
we can't reliably test every code path in services so at least real users should test or implement this
<delroth>
the harden convenience option wouldn't be global but per-service in my proposal -- it's mostly a way to avoid copy-pasting the same 10 lignes everywhere
<clever>
delroth: that does sound like a nice and simple way to handle it
<clever>
and the default for systemd.services.xxx.harden could also change in the future, since you can also just opt-out by setting it to false instead
<fpletz>
but that set of hardening optiona would then be more or less fixed
<fpletz>
clever: how do you test for that?
<clever>
in the future, when a large percentage of services are setting harden = true;, you just commit and change the default
<clever>
and then set harden = false; on anything that gets reported as broken
<clever>
or fix them
janneke has quit [Ping timeout: 250 seconds]
janneke has joined #nixos-dev
<Taneb>
I just created a PR fixing a package that has no maintainers
<qyliss>
want to maintain it? :3
<qyliss>
s/3/;/
<qyliss>
err,
<qyliss>
whatever
<Taneb>
Well, no, I have little interest in it other than it's a broken thing which it turned out I could fix
<Taneb>
But if no-one else will...
<Taneb>
My question was more "Who do I ping about it?"
<qyliss>
whoever you want, I guess
<qyliss>
or people who maintain closely related / dependent packages, if you feel like putting in the effort to find them
<qyliss>
or people who've previously worked on this package
<Taneb>
It's an obscure compiler for a research language, with nothing built by it in nixpkgs
<{^_^}>
#69365 (by arianvp, 5 minutes ago, open): update-users-groups.pl is broken on master. System doesn't boot
<emily>
re that bisect
<arianvp>
at least not for me :P
<arianvp>
emily: yeh but im 50% sure this one is unrelated
mmlb has quit [Remote host closed the connection]
<Taneb>
50% sure is a very unsure amount of sure
<arianvp>
correct
mmlb has joined #nixos-dev
<emily>
are you also 50% sure it's related?
<arianvp>
maybe
<arianvp>
mmlb: i'll be back in a few hours. otherwise available tomorrow
<mmlb>
I'll be around for a while. I've pinged some peeps with better network chops to join here.
ixxie has joined #nixos-dev
<sphalerite>
globin infinisil gchristensen andi-: belated +1 on changing mkRemovedOptionModule to an error generally, although I think I'd prefer removing mkRemovedOptionModule completely
<sphalerite>
maybe
<infinisil>
Why remove it and how?
<gchristensen>
I would very strongly prefer not doing that, and instead start by making it a warning in one release and an error in the next, except in cases where the warning step cannot be taken due to complexity
<samueldr>
+1, warn that it *will* not work while continuing to work, and break the config to force a user choice
jonringer has quit [Ping timeout: 268 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
__monty__ has joined #nixos-dev
drakonis_ has quit [Ping timeout: 246 seconds]
<arianvp>
is there any state preserved between nixos test vms?
<arianvp>
my /var/lib/nixos/uid-map is corrupted when I start a nixos test and all the tests fail
<arianvp>
wondering if it might stuck around from a previous test?
<gchristensen>
okay so globin and I did a quick video call to talk about these removed options thing (cc samueldr) and I agree we should fail. the specific case here is an option was removed, and a new option of a different structure was created, ie: not a rename. this means the configuration needed was totally ignored and a very broken deploy was allowed to go out
drakonis_ has joined #nixos-dev
justan0theruser has joined #nixos-dev
drakonis has joined #nixos-dev
justanotheruser has quit [Ping timeout: 245 seconds]
st8less has quit [Ping timeout: 276 seconds]
justan0theruser has quit [Ping timeout: 265 seconds]
<fpletz>
+1 for fail on mkRemovedOptionModule
marek has quit [Ping timeout: 276 seconds]
marek has joined #nixos-dev
<aanderse>
gchristensen: awesome
justan0theruser has joined #nixos-dev
st8less has joined #nixos-dev
pie_ has quit [Ping timeout: 276 seconds]
ris has joined #nixos-dev
<sphalerite>
not sure whether that should go into 19.09 though?
yorick has quit [Quit: WeeChat 2.4]
yorick has joined #nixos-dev
<samueldr>
if the breaking change exists in it, it should
<arianvp>
mmlb: I guess the best course of action is to see if you can buid a 19.09 variant of the packet nixos image
<arianvp>
and see if some of the network people can reproduce it
pie_ has joined #nixos-dev
orivej has joined #nixos-dev
<mmlb>
Thats all on gchristensen actually, he does all the hard work we just integrate it in!
psyanticy has quit [Quit: Connection closed for inactivity]
<gchristensen>
grahamcofborg-eval — The branch this PR will merge in to does not cleanly evaluate, and so this PR cannot be checked.
<ivan>
it's complaining about attribute 'dev' missing, at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-2-shlevy.ewr1.nix.ci/pkgs/development/compilers/terra/default.nix:37:41