Re: Potential security weakness in Guix services

[Julien Lepiller]

Le 1 février 2021 10:35:56 GMT-05:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>Hi,
>
>Leo Famulari <leo@famulari.name> skribis:
>
>> For clarification: the scenario I currently have in mind, is that
>noone
>> has intentionally introduced a security hole in a service, but rather
>> there's an accidental security bug somewhere in service package, that
>> allows an attacker (I'm assuming the service is accessible from the
>> network) arbitrary code execution *within* the service's process.
>>
>> As it is now, the attacker could overtake the service process, then
>chown
>> and chmod arbitrary directories from there. As a particular example,
>I'm
>> considering e.g. a hypothetical ipfs-service-type. A compromised IPFS
>process
>> shouldn't be able to change /etc/passwd entries. The security of the
>IPFS
>> service itself shouldn't be critical to the security of the system as
>a
>> whole.
>> -----
>>
>> A more specific exapmle:
>>
>> ----- Forwarded message from Maxime Devos <maximedevos@telenet.be>
>-----
>> I seem to have stumbled upon a potential security issue, it has to
>> do with how some services use mkdir-p/perms. For example, in
>knot-activation:
>>
>>    (define (knot-activation config)
>>      #~(begin
>>          (use-modules (guix build utils))
>>          (mkdir-p/perms #$(knot-configuration-run-directory config)
>>                         (getpwnam "knot") #o755)
>>          (mkdir-p/perms "/var/lib/knot" (getpwnam "knot") #o755)
>>          (mkdir-p/perms "/var/lib/knot/keys" (getpwnam "knot") #o755)
>>          (mkdir-p/perms "/var/lib/knot/keys/keys" (getpwnam "knot")
>#o755)))
>>
>> /var/lib/knot/keys/keys is chmodded and chowned, which seems innocent
>enough.
>> However, what if knot whas compromised at some point, and the
>compromised knot
>> process has replaced /var/lib/knot/keys with, say, a symlink to
>/gnu/store?
>
>I’m not sure I understand the threat model.  If Knot has a RCE
>vulnerability, it can be exploited to run anything on behalf of the
>‘knot’ user.
>
>At that point, all the state associated with Knot in /var/lib should be
>considered tainted; new keys should be generated, and so on.
>
>Why focus on the permissions on /var/lib/knot?

My understanding is that, in case of an RCE in knot, the attacker can replace 
/var/lib/knot/* with symlinks to arbitrary files in the FS. When the activation 
procedure is run afterwards, the files being linked to are chowned to the knot 
user, and the attacker can access them.

>Also, every time it’s possible and not redundant with measures already
>implemented by the daemon itself, we should consider using
>‘make-forkexec-constructor/container’ as a further mitigation.
>
>WDYT?
>
>Ludo’.