[PATCH] add access control to daemon socket in shepherd service

Done

Details

2 participants

Ludovic Courtès
Reepca Russelstein

Owner: unassigned

Submitted by: Reepca Russelstein

Severity: normal

Reepca Russelstein wrote on 21 Oct 2024 01:31

Recipients:(address . guix-patches@gnu.org)

Message-ID:87a5eyjqr0.fsf@russelstein.xyz

Passing "--disable-chroot" to guix-daemon makes it possible for the
build users to be taken over by anybody who can start a build: they need
only cause a builder to put a setuid binary in /tmp.  That being said,
there are some situations where it currently can't be avoided, like on
Hurd.  It would also probably be good to have the ability to harden a
guix daemon in general by restricting access to it.  For example,
there's no reason that the ntpd user needs access to the guix daemon
(note that this is distinct from access to the *store*, which is of
course always world-readable).

The attached patch implements that restriction for users of
guix-service-type by limiting access to /var/guix/daemon-socket in
accordance with the user-supplied permissions, user, and group.

Example usage:

------------------------------------
;; Limit access to the guix-daemon socket to members of the "users"
;; group
(modify-services %desktop-services
  (guix-service-type config =>
                     (guix-configuration
                      (inherit config)
                      (socket-directory-perms #o750)
                      (socket-directory-group "users"))))
------------------------------------

- reepca

Attachment: 0001-services-guix-configuration-add-access-control-to-da.patch

Ludovic Courtès wrote on 24 Oct 2024 14:43

Recipients:(name . Reepca Russelstein)(address . reepca@russelstein.xyz)(address . 73925@debbugs.gnu.org)

Message-ID:871q05658b.fsf@gnu.org

Hi,

Reepca Russelstein <reepca@russelstein.xyz> skribis:

Toggle quote (14 lines)> From b5163889efb544cfe83cd2bcb3ebd3a957c95a18 Mon Sep 17 00:00:00 2001
> Message-ID: <b5163889efb544cfe83cd2bcb3ebd3a957c95a18.1729465936.git.reepca@russelstein.xyz>
> From: Reepca Russelstein <reepca@russelstein.xyz>
> Date: Sat, 19 Oct 2024 22:43:27 -0500
> Subject: [PATCH] services: guix-configuration: add access control to daemon
>  socket.
>
> * gnu/services/base.scm
>   (guix-configuration-socket-directory-{perms,group,user}): new fields.
>   (guix-shepherd-service): use them.
> * doc/guix.texi: document them.
>
> Change-Id: Ic228377b25a83692b0c637dafbd03c4609e332fc

That’s a welcome addition.

Toggle quote (2 lines)

> +@item @code{socket-directory-perms} (default: @code{#o755})

s/perms/permissions/

Toggle quote (6 lines)

> +Permissions to set for the directory @file{/var/guix/daemon-socket}.

> +This, together with @code{socket-directory-group} and

> +@code{socket-directory-user}, determines who can connect to the guix

> +daemon via its unix socket. TCP socket operation is unaffected by

> +these.

s/guix daemon/build daemon/ and s/unix/Unix/

Toggle quote (8 lines)

> +@item @code{socket-directory-group} (default: @code{#f})

> +Group to set for the directory @file{/var/guix/daemon-socket}, or

> +@code{#f} to keep its group as root.

> +

> +@item @code{socket-directory-user} (default: @code{#f})

> +User to set for the directory @file{/var/guix/daemon-socket}, or

> +@code{#f} to keep its user as root.

Maybe group them together:

@item @code{socket-directory-user} (default: @code{#f})

@itemx @code{socket-directory-group} (default: @code{#f})

User and group owning the @file{/var/guix/daemon-socket} directory.

…

Toggle quote (6 lines)

> - (guix build-group build-accounts authorize-key? authorized-keys

> - use-substitutes? substitute-urls max-silent-time timeout

> - log-compression discover? extra-options log-file

> - http-proxy tmpdir chroot-directories environment)

> + (guix build-group build-accounts authorize-key? authorized-keys

Please avoid reindenting.

Toggle quote (12 lines)> +                  ;; Ensure that a fresh directory is used, in case the old
> +                  ;; one was more permissive and processes have a file
> +                  ;; descriptor referencing it hanging around, ready to use
> +                  ;; with openat.
> +                  (false-if-exception
> +                   (delete-file-recursively "/var/guix/daemon-socket"))
> +                  (let ((perms #$(logand socket-directory-perms
> +                                         (lognot #o022))))
> +                    (mkdir "/var/guix/daemon-socket" perms)
> +                    ;; Override umask
> +                    (chmod "/var/guix/daemon-socket" perms))

Speaking of ‘openat’, maybe use ‘mkdir-p/perms’ instead of doing it in

two steps?

Apart from that it LGTM.

Could you send an updated patch?

Thanks,

Ludo’.

Reepca Russelstein wrote on 26 Oct 2024 02:10

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 73925@debbugs.gnu.org)

Message-ID:87wmhvhgg7.fsf@russelstein.xyz

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (15 lines)>> +                  ;; Ensure that a fresh directory is used, in case the old
>> +                  ;; one was more permissive and processes have a file
>> +                  ;; descriptor referencing it hanging around, ready to use
>> +                  ;; with openat.
>> +                  (false-if-exception
>> +                   (delete-file-recursively "/var/guix/daemon-socket"))
>> +                  (let ((perms #$(logand socket-directory-perms
>> +                                         (lognot #o022))))
>> +                    (mkdir "/var/guix/daemon-socket" perms)
>> +                    ;; Override umask
>> +                    (chmod "/var/guix/daemon-socket" perms))
>
> Speaking of ‘openat’, maybe use ‘mkdir-p/perms’ instead of doing it in
> two steps?

PERMS is passed directly to mkdir; the umask may cause the permissions
the directory is created with to be less permissive than those, but
never more.  The only reason I call chmod here is because the umask may
happen to be more strict than PERMS.  mkdir-p/perms creates the
directory with the permissions initially restricted only by the umask,
then later chmods it in a separate step, leaving a window during which
the directory is likely world-executable and world-readable.  So while
mkdir-p/perms would be an improvement on the "make sure no components
are symlinks" front, it would be a downgrade in restricting access to
the directory.

This behavior can be remedied by ensuring that the final call to
'mkdirat' passes in the specified permission bits.  I've submitted a
patch to do this in issue #74002.

There's also a minor annoyance in that the 'owner' argument that
mkdir-p/perms wants MUST be a passwd object.  This means that the uid
and gid to use can't be specified independently, nor can they be
specified as -1 or 0, you *have* to do (getpwnam "root") or something
similar.

For now I'm going to keep this part as-is, since currently using
mkdir-p/perms would neither make it more secure nor more concise.

The attached patch incorporates all the other changes you've mentioned.

- reepca

Attachment: 0001-services-guix-configuration-add-access-control-to-da.patch

Ludovic Courtès wrote on 3 Nov 2024 23:05

Recipients:(name . Reepca Russelstein)(address . reepca@russelstein.xyz)(address . 73925-done@debbugs.gnu.org)

Message-ID:87h68okm6d.fsf@gnu.org

Reepca Russelstein <reepca@russelstein.xyz> skribis:

Toggle quote (14 lines)> From b8ea0288a35c27912580bd7fe861dd6e497f4c33 Mon Sep 17 00:00:00 2001
> Message-ID: <b8ea0288a35c27912580bd7fe861dd6e497f4c33.1729840060.git.reepca@russelstein.xyz>
> From: Reepca Russelstein <reepca@russelstein.xyz>
> Date: Sat, 19 Oct 2024 22:43:27 -0500
> Subject: [PATCH] services: guix-configuration: add access control to daemon
>  socket.
>
> * gnu/services/base.scm
>   (guix-configuration-socket-directory-{permissions,group,user}): new fields.
>   (guix-shepherd-service): use them.
> * doc/guix.texi: document them.
>
> Change-Id: I8f4c2e20392ced47c09812e62903c87cc0f4a97a

Applied, thanks!

Closed

Your comment

This issue is archived.

To comment on this conversation send an email to 73925@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 73925

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date