least-authority-wrapper and make-forkexec-constructor composition problem

  • Open
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal
M
M
Maxim Cournoyer wrote on 17 Jan 2023 20:30
(name . bug-guix)(address . bug-guix@gnu.org)
87zgahyn5w.fsf@gmail.com
Hi,

I'm creating a bug to keep track of a problem that was uncovered when
attempting to migrate the jami-service-type service to use the
least-authority-wrapper [0], to avoid forgetting about it.

It was found that using something like:

Toggle snippet (8 lines)
(make-forkexec-constructor
(least-authority
(list (file-append coreutils "/bin/true"))
(mappings (delq 'user %namespaces))
#:user "nobody"
#:group "nobody"))

Would fail with EPERM, because in order to be able to drop the user
namespace, the CAP_SYS_ADMIN capability is required, but in the above
case, make-forkexec-constructor has already changed the user to
"nobody", which lacks such capability.

The solution proposed by Ludovic in would be to [1]:

Toggle quote (4 lines)
> [...] add #:user and #:group to ‘least-authority-wrapper’ and
> have it call setuid/setgid. ‘make-forkexec-constructor’ doesn’t need to
> be modified, but the user simply won’t pass #:user and #:group to it.


--
Thanks,
Maxim
L
L
Ludovic Courtès wrote on 19 Jan 2023 18:04
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 60890@debbugs.gnu.org)
87pmba8nhp.fsf@gnu.org
Hello!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Toggle quote (14 lines)
> It was found that using something like:
>
> (make-forkexec-constructor
> (least-authority
> (list (file-append coreutils "/bin/true"))
> (mappings (delq 'user %namespaces))
> #:user "nobody"
> #:group "nobody"))
>
> Would fail with EPERM, because in order to be able to drop the user
> namespace, the CAP_SYS_ADMIN capability is required, but in the above
> case, make-forkexec-constructor has already changed the user to
> "nobody", which lacks such capability.

Thanks for the reminder!

I guess the problem is limited to cases where you need the program to
run in the global user namespace.

For example, Tor does not need to run in the global user namespace, and
thus does the following:

Toggle snippet (19 lines)
(define (tor-shepherd-service config)
"Return a <shepherd-service> running Tor."
(let* ((torrc (tor-configuration->torrc config))
(tor (least-authority-wrapper
(file-append (tor-configuration-tor config) "/bin/tor")
#:name "tor"
#:mappings (list …)
#:namespaces (delq 'net %namespaces))))
(list (shepherd-service
(provision '(tor))
;; …
(start #~(make-forkexec-constructor
(list #$tor "-f" #$torrc)
#:user "tor" #:group "tor"))
(stop #~(make-kill-destructor))
(actions (list (shepherd-configuration-action torrc)))
(documentation "Run the Tor anonymous network overlay.")))))

Here ‘make-forkexec-constructor’ calls setuid/setgid before it invokes
the wrapped program, and everything’s fine.

Ludo’.
M
M
Maxim Cournoyer wrote on 20 Jan 2023 14:42
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 60890@debbugs.gnu.org)
87lelxcofy.fsf@gmail.com
Hi,

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

Toggle quote (23 lines)
> Hello!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> It was found that using something like:
>>
>> (make-forkexec-constructor
>> (least-authority
>> (list (file-append coreutils "/bin/true"))
>> (mappings (delq 'user %namespaces))
>> #:user "nobody"
>> #:group "nobody"))
>>
>> Would fail with EPERM, because in order to be able to drop the user
>> namespace, the CAP_SYS_ADMIN capability is required, but in the above
>> case, make-forkexec-constructor has already changed the user to
>> "nobody", which lacks such capability.
>
> Thanks for the reminder!
>
> I guess the problem is limited to cases where you need the program to
> run in the global user namespace.

Yes, it's limited to that case, because when clone(2) is called without
CLONE_NEWUSER, the child process does *not* start with a complete set of
capabilities (CAP_SYS_ADMIN), quoting my original investigation from
[0]:

Toggle quote (7 lines)
> The problem then seems to be that since we need CAP_SYS_ADMIN when
> dropping the user namespace, as CLONE_NEWUSER is what gives us
> superpowers. Per 'man user_namespaces':

> The child process created by clone(2) with the CLONE_NEWUSER flag starts
> out with a complete set of capabilities in the new user namespace.


--
Thanks,
Maxim
?