Re: Potential security weakness in Guix services

[Ludovic Courtès]

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?

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’.