<copumpkin>
niksnut: the idea of calling it privilege escalation is that the logs actually show (although the link in shlevy's email broke) <unprivileged process> killed <privileged process>
<copumpkin>
but I'm not putting things into the store in a conventional way
<copumpkin>
for image building
<gchristensen>
how else can you get things in to the store?
<copumpkin>
well, it's the store inside an image, so it's using cptofs and LKL
<gchristensen>
oh I see, ouch
<copumpkin>
yup
<niksnut>
copumpkin: sure, but it doesn't allow you to do anything more than bring down the system (a DoS)
<niksnut>
which on macOS you can do anyway by hitting the power button
<copumpkin>
niksnut: well, our point was that since we can't explain why an unprivileged process could signal a privileged one yet, the vulnerability might well be exposed in more targeted ways
<gchristensen>
niksnut: an unprivileged process inside a sandbox can do it
<copumpkin>
we just happened to find it in kill(-1, ...)
<copumpkin>
niksnut: in more annoying news, are you in the mood to generate new 17.09 AMIs? :) :) :) the current ones are very slightly (but annoyingly) broken and it's my fault :(
<niksnut>
sure
<niksnut>
what's broken?
<copumpkin>
the timestamps on some store files, which can break further image creation. I'll fix master and backport to 17.09 and let you know when that's done
<copumpkin>
so basically the new image builder is fine
<copumpkin>
but running the new image builder inside images built by itself breaks
<copumpkin>
niksnut: on a slightly related note (not for 17.09), do you feel strongly about grub vs. extlinux on EC2?
<peti>
domenkozar: Can you please push the new docker image for Nix to docker hub? Or, alternatively, can we please have an automatic build of that file? docker hub supports that kind of thing, no?
<niksnut>
extlinux? :o
<niksnut>
does that still exist?
<copumpkin>
seems to :P
<niksnut>
why not lilo? :p
<gchristensen>
lilo++
<copumpkin>
lol
<copumpkin>
my motivations are shady, I admit
<copumpkin>
sys/extlinux doesn't need a VM to install itself :P
<niksnut>
I think we're better of with as few boot loaders as possible
<gchristensen>
I think it would be a mistake to not try and find a way to support multi-user on darwin
<gchristensen>
man, so many discussions :P
<copumpkin>
so it would let me kill the last remaining VM in the image builder
<copumpkin>
anyway I won't change anything yet, but it still seems to both exist and be supported by nixos
<copumpkin>
gchristensen: yeah, shlevy and I were noodling about ways to kill all user processes safely on macos
<copumpkin>
they were doable but kind of annoying
<domenkozar>
peti: I thought I did already? Or were there some further changes?
phreedom has quit [(Remote host closed the connection)]
<zimbatm>
grahamc: is there any value for "multi-user" aside from the sandbox?
<zimbatm>
maybe a better name is "service" or "system" installation
<gchristensen>
or "actually reproducible" or "the one where pip won't break your nix install"
<zimbatm>
the /nix/store is writeable in a single-user install?
<gchristensen>
yeah
<zimbatm>
!!!
<gchristensen>
that's what I'm saying! :o
<gchristensen>
I don't use nix-daemon on NixOS b/c I have multiple users
<gchristensen>
I use it b/c it works and the other way lies to you
<gchristensen>
it is why I worked so hard on the multi-user install for darwin, so I could recommend my coworkers use it. it being broken on HS is a deal-breaker obviously, but if we can't fix the multi-user part I won't be able to recommend it anymore
<zimbatm>
HS == new release?
<zimbatm>
new darwin release?
<gchristensen>
yeah, High Sierra
<zimbatm>
so we should rename the "single user" to "toy" or "shabby"
<zimbatm>
and "multi-user" to "proper" :)
<gchristensen>
IMO yes, something like that
<zimbatm>
single-user is for users that want to test nix
<domenkozar>
we could do that once our mainly used installer doesn't use single user
<zimbatm>
the nice thing about it is that you can tell users that they just have to rm -rf /nix; rm -rf .nix-*` and remove the .bashrc reference and it's gone
<gchristensen>
well ideally we'd rename single-user / multi-user to something that describes them better
<zimbatm>
is there any opportunity for doing the change as part of the nix 1.12 release?
<gchristensen>
zimbatm: the nice thing about haskell I hear is if you put `-- effectful` and `-- no-referenttial-integrity` at the top of your file you can use IO wherever you want, and have functions return different things with the same parameters
<zimbatm>
do you mean it's nice to be able to be impure from time to time?
<zimbatm>
but it has to be explicit
<gchristensen>
no, I'm lying. I mean to get the benefits you have to do the work
<gchristensen>
the easy uninstall, I think, is a red herring
<zimbatm>
it could be solved by providing an uninstall script
<gchristensen>
yeah :)
<zimbatm>
actually that would be much better, only 1 command to run :)
<zimbatm>
copumpkin: when I still had a mac, 90% of my packages where sourced from nixpkgs but some where still problematic. from memory: anything with gpg like git-crypt, heroku
<domenkozar>
peti: if you know how to set automatic builds for docker, I'm happy to hook that up
<zimbatm>
there were the times where go programs could segfault, it was handy to have homebrew as a fallback
<peti>
domenkozar: If you can give me access to the docker hub project, then I can set-up the auto-builds.
<zimbatm>
I don't mind giving you access and when it's ready we can move it to the nixos org
<peti>
zimbatm: Hmm, that image seems to be an outdated version of what we have in the Nix repository in misc/docker.
<zimbatm>
maybe, I had to make a couple of tweak to fix ssl issues
<peti>
zimbatm: We have a decent Docker file in the Nix repo, but what we don't have is an auto-build on docker hub that provides the latest version of that image every time the Dockerfile changes in git.
<zimbatm>
I don't think that's right, the version of nix is hard-coded in misc/docker
<zimbatm>
docker hub maps the git tags to docker tags and master to :latest
<zimbatm>
but every time master is being pushed here, it would still build the fixed version number that's pulled inside the Dockerfile
<zimbatm>
it would be easier to maintain that in a separate repo so you can first do the nix release, the update the docker-nix repo with that release and tag it
<zimbatm>
at least with the current approach
<zimbatm>
ok I see the default profiles have changed
<peti>
zimbatm: IMHO the current state is perfectly fine. "latest" refers to whatever is the latest version that we have in the docker image.
<zimbatm>
I think it would be confusing to pull nixos/nix:1.12 and still get the 1.11 version
<peti>
zimbatm: Nobody creates nixos/nix:1.12.
<MoreTea>
domenkozar, peti I just played a bit with using the multi-stage Dockerfile image feature. It appears that we can bootstrap a pristine nix docker image quite easily using that.
<peti>
zimbatm: The auto-build just pushes to "latest". Everything else would need manual triggers at the moment.
<zimbatm>
in any case auto-build would already be an improvement
<zimbatm>
ideally, the Dockerfile would build the nix code that's in the repo, using a multi-stage Dockerfile. then everything could map 1:1 to the repo code
<domenkozar>
can we tell dockerhub to only build master?
<zimbatm>
yes
<zimbatm>
that would be a quick win
<MoreTea>
domenkozar, you can set up rules like: this branch should be published under tag $X
<domenkozar>
MoreTea: would that reduce image size? or what's the intention
<gchristensen>
some discussions on solving the H.S. problem include reapplying a tighter sandbox to the build user (if possible, to be determined) which prevents forking, enumerating all the processes (using the atomic syscall KERN_PROC_UID) killing them all, and repeating this loop until there are no processes by the user.
shlevy has joined joined #nixos-dev
<gchristensen>
copumpkin: where would I go to learn about sandbox_add_extension?
<copumpkin>
the function is gone and this has all been gleaned from reverse engineering in the first place
<copumpkin>
apple doesn't document any of that
<gchristensen>
I thought you said sandbox_create_extensions was gone, not _add_extension
<copumpkin>
there are a couple of docs I posted the other day from reverse engineering
<copumpkin>
did I mention _add_extension? I don't see such a function
<taktoa>
woops, didn't mean to put a preceding space there
<taktoa>
I guess that's as good a way as any to float the idea of such a channel :-)
<gchristensen>
what is -blah for? :)
<simpson>
Good idea but I fear that it won't fix #nixos.
<taktoa>
gchristensen: like haskell-blah
<gchristensen>
oh
<clever>
gchristensen: reguarding the high seira bug, what special powers might other signals have?, what if i SIGHUP or SIGUSR1 every process on the machine?
<copumpkin>
niksnut: you thinking of expanding on the seccomp stuff to kill syscalls that most builds wouldn't need? or do you trust the namespacing stuff enough?
<copumpkin>
would be nice if seccomp had a nicer front-end language like the mac sandboxing stuff
__Sander__ has quit [(Quit: Konversation terminated!)]
<niksnut>
copumpkin: I did considered killing buildings instead of returning EPERM/ENOTSUP
<copumpkin>
but things like disabling the shutdown syscall for example
<copumpkin>
erm wrong one
<copumpkin>
sys_reboot, settimeofday, etc. :P
goibhniu has quit [(Ping timeout: 255 seconds)]
<gchristensen>
can unpriveleged users call those? interesting :)
<gchristensen>
can graham learn to spell "unprivileged"? let's find out
<copumpkin>
I'd hope not :) mostly just wondering if we want to do a paranoid seccomp call in case other mechanisms get circumvented
<gchristensen>
I, for one, hope that I can learn to spell
<disasm>
is advertising a freelancer bounty appropriate for nix-devel? at least they aren't asking for money I guess.
<MichaelRaskin>
I cannot deny that the bounty being advertised is relevant for Nixpkgs development.
<clever>
gchristensen: hydra emailed me about https://hydra.nixos.org/build/61683847 failing, but the logs for qtbase say it didnt fail, what happens if you restart it?
<gchristensen>
hmm not sure
<gchristensen>
should I restart it?
<clever>
yeah
<gchristensen>
done
<clever>
gchristensen: its still listing as aborted
<copumpkin>
seems up our alley re: the distributed build verification thing
<copumpkin>
their merkle tree thing is unnecessary with nix
<copumpkin>
at least with our setup
<MichaelRaskin>
Well, we would need bit-perfect builds
<MichaelRaskin>
And then all that stuff about tracking the repository fate so that a single-machine compromise doesn't poison it (including GitHub compromise.)