Can we have less capabilities

[Aleksanaa]

https://github.com/OkamiW/proxy-ns/blob/master/Makefile#L21

cap_net_bind_service,cap_fowner,cap_chown,cap_sys_chroot,cap_sys_admin,cap_net_admin=ep this is very close to root

[deng232]

I don't know exactly how does it drop capabilities ( maybe because target process run as nobody 65534) , the target process don't inherit capabilities of the origin process (execve). However in nixos somehow the capabilites being inerited in my test, I see what i can do.

but still, I doubt do we need that much of capabilites to just run proxy-ns itself? and I'm curious how does it drop the privilige for the target process

[OkamiW]

All capabilities used are dropped before the main loop: https://github.com/OkamiW/proxy-ns/blob/v2.2.2/main.go#L157

Explanations for the required capabilities:

• fowner, chown,chroot are for mounting a separate /etc/resolv.conf, and changing the owner to root.
• net_bind_service is for the fake DNS service listening on 127.0.0.1:53
• sys_admin is for switching namespaces.
• net_admin is for tun device inside the proxy-ns network namespace.

In theory, we could utilize User Namespace.
However, unprivileged user namespace cloning is often disabled for security reasons.

[OkamiW]

I agree proxy-ns is using a lot of capabilities, which makes it look scary on a glimpse, but I would argue it's still better than SUID.

The capabilities are only used for namespace setup, then the main process exec into the target process, with all capabilities lost. The daemon process also drop the privileges at the beginning of the execution, with PR_SET_NO_NEW_PRIVS set.

There could be a user namespace mode though.
When proxy-ns doesn't have the required capabilities and kernel.unprivileged_userns_clone=1, it could automatically fallback to it.

[OkamiW]

I just realized CAP_FOWNER isn't really necessary, since we're doing chmod before chown.
I've pushed a fix to remove that capability.

[deng232]

All capabilities used are dropped before the main loop: https://github.com/OkamiW/proxy-ns/blob/v2.2.2/main.go#L157

Explanations for the required capabilities:

* ~fowner,~ chown,chroot are for mounting a separate `/etc/resolv.conf`, and changing the owner to root.

* net_bind_service is for the fake DNS service listening on 127.0.0.1:53

* sys_admin is for switching namespaces.

* net_admin is for tun device inside the `proxy-ns` network namespace.

In theory, we could utilize User Namespace. However, unprivileged user namespace cloning is often disabled for security reasons.

can I assume even dropPrivilege() executed in child process but it still affect its parent process through AllThreadsSyscall6?
and in what way does dropPrivilige() must execute before unix.Exec() change process to target process?

what if the parent process is execute in script via an wrapper (wrapper.c calling execve(proxy-ns) to switch to proxy-ns, wrapper has caps) with "capabilities" and the child process is the original bin with no capabilities will this case break the capabilities dropping for the target process?

so far I found that nixos wrapping the program and calling PR_CAP_AMBIENT_RAISE thus capabilites may some inherited to the target process, may we have ambient_lower or ambient_clear in dropPrivilige? just tested, not likely this. if I add additional dropPrivilige before os.Exec, it drop sucessful in nixos

[OkamiW]

can I assume even dropPrivilege() executed in child process but it still affect its parent process through AllThreadsSyscall6? and in what way does dropPrivilige() must execute before unix.Exec() change process to target process?

dropPrivilege only affects the child process(the proxy-ns daemon), since it's called at the very beginning in child process, it practically makes the child process non-privileged.

The parent process is privileged from the beginning. It sets up the namespace, then exec into the target process. Linux would clear the capabilities if the target process is not privileged.(For details, see Transformation of capabilities during execve() in capabilities(7) )

what if the parent process is execute in script via an wrapper (wrapper.c calling execve(proxy-ns) to switch to proxy-ns, wrapper has caps) with "capabilities" and the child process is the original bin with no capabilities will this case break the capabilities dropping for the target process?

proxy-ns only drops its own privileges. It doesn't interfere with the target process's privileges(Since it's not a sandbox).
If the target process isn't privileged, it stays unprivileged.
If the target process is privileged, it can get any privileges it can get without proxy-ns.

so far I found that nixos wrapping the program and calling PR_CAP_AMBIENT_RAISE thus capabilites may some inherited to the target process, may we have ambient_lower or ambient_clear in dropPrivilige?

Refer to Thread capability sets in capabilities(7):

Executing a program that changes UID or GID due to the set-user-ID or set-group-ID bits or executing a program that has any file capabilities set will clear the ambient set.

proxy-ns has file capabilities set, so Linux would clear the ambient set when the wrapper program exec into proxy-ns.

[deng232]

that sounds good, now I'm suspect the wrapper adding inheritable to itself.
I found it it the strace and the target process end up with caps caps: cap_chown,cap_fowner,cap_net_bind_service,cap_net_admin,cap_sys_chroot,cap_sys_admin=eip cap_setpcap+i

[OkamiW]

that sounds good, now I'm suspect the wrapper adding inheritable to itself. I found it it the strace and the target process end up with caps caps: cap_chown,cap_fowner,cap_net_bind_service,cap_net_admin,cap_sys_chroot,cap_sys_admin=eip cap_setpcap+i

That's very curious. I will test it on a NixOS host later.

[OkamiW]

that sounds good, now I'm suspect the wrapper adding inheritable to itself. I found it it the strace and the target process end up with caps caps: cap_chown,cap_fowner,cap_net_bind_service,cap_net_admin,cap_sys_chroot,cap_sys_admin=eip cap_setpcap+i

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/security/wrappers/wrapper.c#L104
The wrapper does set inheritable.

Also, I think NixOS may not set file capabilities(Which is why they're using a wrapper program).
This breaks my assumption:

proxy-ns has file capabilities set, so Linux would clear the ambient set when the wrapper program exec into proxy-ns.

So the target program would ends up with the parent process's capabilities...

[OkamiW]

I just pushed a fix for ambient capabilities on master.
Capabilities should be properly dropped for target program now.

[deng232]

yes, the proxy-ns-wrapper has file capabilities and merge inheritable to all caps, and raise caps to ambient set in runtime;
proxy-ns is not priviliged( no suid or guid presented in ls -al) nor with any caps;
the ambient set keep passing ep set from wrapper to proxy-ns to target process since last two were no privilege.

anyway, the fix has no more caps inherit from the wrapper, target process with its own caps now.