Re: Tracking and inspecting how Guix changes over time

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 3082 bytes --]


Christopher Baines <mail@cbaines.net> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello!
>>
>> Christopher Baines <mail@cbaines.net> skribis:
>>
>>> As far as I can see, guix pull/the channels code directly evaluates some
>>> Guile code from the source repository. It would be great if this could
>>> somehow be isolated to guard against any malicious patches that try to
>>> attack the machine running the Guix Data Service, I haven't thought much
>>> about how yet.
>>>
>>> Similarly, using the inferiors approach to extract out information from
>>> Guix requires running a REPL from the target Guix. This could also pose
>>> security issues. I was wondering if it was possible to run the REPL
>>> within a container, to at least isolate it a bit from the system.
>>
>> Yes, we should definitely run that code in a container.  Note that, for
>> ‘guix pull’, I think it’s OK to run that code on the user’s machine
>> as-is in the sense that the user is going to run code coming from the
>> channels they specified anyway.
>>
>> For an automated system like this, it’s a bit different, so using a
>> container makes a lot of sense.  I’d suggest having an option directly
>> in (guix inferior) to allow users to choose whether to run an inferior
>> in separate name spaces.  WDYT?
>
> That sounds great, I'm not quite sure how to make it happen though...
>
> So inferior-pipe in (guix inferior) uses open-pipe*. The root of the
> Linux container code in Guix looks to be run-container (gnu build
> linux-container).
>
> The run-container function uses the clone syscall with the right flags
> to isolate the new child process. I've looked at the (ice-9 popen)
> module, and the couple of C functions it uses (scm_open_process and
> start_child). Calling open-pipe* eventually calls fork, which I think
> uses the clone syscall as well.
>
> I can't quite work out how to combine the two though. I'm unsure how to
> add the pipe behaviour to run-container, and it seems infeasible to get
> open-pipe* to call fork/clone with the right flags.
>
> Any ideas? I included David as he appears to have been involved in the
> initial container implementation in case he had any wise suggestions.

So, I've now got around to looking at this some more. My initial
approach was to wrap the pipe/dup2 calls made within the C part of
open-pipe*, but while doing this, I discovered that Guile already has
wrappers for these things.

So, I've now got an initial prototype that I've put up here [1], and
I've been able to adjust the guix-data-service to make use of this. I've
moved doing the 'guix pull' bit inside the an inferior as well, so all
of the code fetched from the internet can be isolated through the
inferior.

I'm still not sure exactly how much isolation it provides, and I haven't
really tested it, apart from hitting issues where the isolation was
breaking the code I was trying to make work inside the inferior. Anyway,
it's a start.

1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34638

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]