erictapen has quit [Ping timeout: 272 seconds]
pie_ has quit [Ping timeout: 268 seconds]
r5d has joined #nixos-security
MichaelRaskin has quit [Ping timeout: 244 seconds]
MichaelRaskin has joined #nixos-security
<ekleog> oh another one :D https://seclists.org/oss-sec/2018/q4/123
<andi-> never ending story :-)
periklis has joined #nixos-security
<ckauhaus> periklis: Hi, I was the last 3 days on travel
<ckauhaus> I'll catch up with the various open questions today
<ckauhaus> need to get sorted beforehand...
<periklis> ckauhaus: no rush & sorry for the pile of questions
<ckauhaus> periklis: you are very welcome to ask all sort of questions :)
<ckauhaus> I'm glad for everyone who cares
erictapen has joined #nixos-security
erictapen has quit [Ping timeout: 240 seconds]
<andi-> so that release-rebuild I started yesterday is finished besides chromium and some qtwebkit stuff.. Looks good. Would prefer if someone else also has a look onto the proposed patch(es) and the impact.
erictapen has joined #nixos-security
erictapen has quit [Ping timeout: 252 seconds]
__Sander__ has joined #nixos-security
<ckauhaus> andi-: yeah
<ckauhaus> a quick URL at hand with the diff?
<{^_^}> systemd#25 (by andir, 13 hours ago, open): include NixOS current system bin & sbin paths in DEFAULT_PATH*
periklis has quit [Remote host closed the connection]
periklis has joined #nixos-security
periklis has quit [Remote host closed the connection]
<ckauhaus> andi-: I wonder if this is the right thing to do
<ckauhaus> Do I get this right that with this patch, systemd uses whatever someone else has but into systemPackages?
<andi-> yes, which seemed to be the case previously if we see how we invoke systemd in stage-2.sh
<andi-> at least that is what I still remember from yesterday
<ckauhaus> it's not a very Nixy way to do it
<andi-> oh, acutally, what we do there is PATH=/run/current-system/systemd/lib/systemd:@fsPackagesPath@ \
<ckauhaus> ic
<andi-> but we can't pull in fsPackagesPath there
<ckauhaus> better
<andi-> because that would rebuild the system whenever you change filesystem packages...
<ckauhaus> wouldn't it be better to explicitely reference the required tools in the generators?
<andi-> fsPackagesPath is modified by nixos modules
<andi-> so if someone uses a filesystem that we havent heard of before it breaks for them...
<andi-> or it would require everyone having all the tools all the time
<ckauhaus> yes, sorta problematic
<ckauhaus> why can't we pull in fsPackagePath?
<ckauhaus> this path is expected to change not so often
<ckauhaus> this is how it is done today
<ckauhaus> or do I miss some important point?
<ckauhaus> I'd rather tolerate a rebuild of the generators when I mess around with fsPackages instead of having systemd whatever happens to be in systemPackages
<ckauhaus> this is what your PR is going to achieve, right?
<andi-> It is not a rebuild of generators. It is a rebuild of the entire system (well everything that depends on systemd in some way)
<ckauhaus> this is what it does today, right?
<ckauhaus> hmm
<andi-> no
<ckauhaus> just wire up the path in the generator units?
<andi-> there are no units for them
<andi-> systemd executes everything from the generators directory
<ckauhaus> so is there really no way of putting the path in some config file instead of compiling it into the binary?
<andi-> we can add some code to systemd that reads it
<ckauhaus> would perhaps be a better hack than relying on systemPackages
<andi-> fsPackages are pulled into systemPackages that is why I thought this would be a workable hack... It isn't pretty. We could instead also patch the generator execution. I just fear that with more and more systemd motifications the maintenance of it will not become easier over time.
<ckauhaus> that's right of course
<ckauhaus> would systemPackages be there for any systemd unit then?
<ckauhaus> this would be a huge impurity
<andi-> I don't think so. Grepping for DEFAULT_PATH seemed relativly harmless but it a lot of indirections in the code and multiple "resolving" types ending up in the same functions..
<ckauhaus> would perhaps be worth a short experiment
<ckauhaus> having systemPackages available only in the generators and other built-in units but not generally would be an acceptable compromise IMHO
* ckauhaus wonders if someone else has an opinion on this, too
<andi-> systemd-run env shows path from previosuly being FHS style (PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin) to be PATH=/run/current-system/sw/sbin:/run/current-system/sw/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin with those changes..
<andi-> so yeah, systemPackages would be available then.. I leave the judging to others. I would just like to get this fixed one way or another.
<andi-> wait, that old style was from my notebook which has the "patched" systemd...
<andi-> https://gist.github.com/andir/75ba19131d716449b37b4b889b833c30 this is from my other device... so it actually uses /run/current-system/sw/bin/env whenever you try to exec something..
<ckauhaus> looks not too bad
<andi-> the gist is from my 18.03 test system.. so that shoudl be the "old" nixos behaviour
<ckauhaus> would the new stuff be the same?
<andi-> 1) it still finds `env` when i just systemd-run but that is a corner case I believe 2) the output changed from PATH=/no-such-path to the DEFAULT_PATH as defined in the code. I think we might need to investigate there. I can only do that in the evenings.. I need to get some paid work done and then catchup on sleep.
<ckauhaus> no hurry
<andi-> well 18.09 & master are blocked by this...
<ckauhaus> but better come up with a smart solution after getting some sleep :)
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-security
__Sander__ has quit [Quit: Konversation terminated!]
tv has joined #nixos-security
<ekleog> this needs merge: https://github.com/NixOS/nixpkgs/pull/37365 … fixes CVSS3 9.5 in the version of bacula we currently have
<{^_^}> #37365 (by proteansec, 32 weeks ago, open): bacula: 5.2.13 -> 9.2.1
<ekleog> CVE-2017-15367
<ekleog> I don't really believe in backporting the patch to our version for 18.09 as it's way older than the one for which the patch was made, but can try doing it (though I won't be able to do much more than check if it builds, and given it's PHP it won't mean much) if you think it'd be better than backporting the whole update
<andi-> bacula is php? o.O thats new to me
<ekleog> well, bacula-web (where the vuln is) at least is, if I read the patch correctly https://github.com/bacula-web/bacula-web/commit/90d4c44a0dd0d65c6fb3ab2417b83d700c8413ae
<andi-> ok, personally I would push towards more tests and mark the old version as insecure with reference to the known issues.
<ekleog> actually I just noticed maybe our bacula package doesn't include bacula-web and I'm crying wolf
<andi-> I added it to my todo list will see about it tomorrow..
<ekleog> … yeah ok now I feel stupid
<ekleog> so there's no vuln here, sorry, we just don't have bacula-web packaged :/
<andi-> happens :-)
<andi-> thanks for caring!
<ekleog> :)
pie_ has joined #nixos-security
pie_ has quit [Ping timeout: 272 seconds]
<andi-> So I did a bit more digging through our changesets of the systemd fork and it seems like initially elco set that path to '/no-such-path' but we lost that since we had v239 it just never surfaced.. Time to work on a proper solution for this..
erictapen has joined #nixos-security
pie_ has joined #nixos-security
pie_ has quit [Ping timeout: 268 seconds]
pie_ has joined #nixos-security
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-security
pie_ has quit [Excess Flood]
pie_ has joined #nixos-security
pie_ has quit [Ping timeout: 245 seconds]
ckauhaus has quit [Quit: WeeChat 2.2]
pie_ has joined #nixos-security
pie_ has quit [Ping timeout: 268 seconds]
pie_ has joined #nixos-security
copumpkin has quit [Read error: Connection reset by peer]
copumpkin has joined #nixos-security