A question on usage of POSIX capabilities in Wine

[ChrysoliteAzalea]

Hello everyone! I've noticed that in the FAQ, there is an advice to add file capabilities on the Wine binary, I wonder, what is the reason to set the capability as both permitted and inheritable? If a file capability is set as permitted, it will be granted as long as it has not been cut from the capability bounding set, and if it's set as inheritable, it will only be granted if it's inheritable for the process that runs it. So, "permitted+inheritable" file capabilities is effectively equivalent to just permitted. If solutions such as pam_cap are not used, then it's worth setting it to simple "permitted+effective", but that's a security risk since that means that all Wine apps will get the capability (which can be used maliciously). The more secure solution is to set it as "inheritable+effective", but to get it working, users will have to use the "pam_cap" module in order to have necessary capabilities in their inheritable capability set. Then, Wine can be run using a wrapper script that uses the setpriv program to drop unnecessary inheritable capabilities (so they do not become permitted and effective for the Wine app) -- for example, ping can be run with CAP_NET_RAW capability, some server apps can be run with CAP_NET_BIND_SERVICE capability, and ordinary apps may be run without capabilities.

Example for keeping CAP_NET_BIND_SERVICE inheritable capability and removing all others:

Code: Select all

setpriv --inh-caps -all,+NET_BIND_SERVICE wine $app

Example for removing all inheritable capabilities:

Code: Select all

setpriv --inh-caps -all wine $app

Warning: Wine apps are generally capability-unaware (since POSIX capabilities do not exist in Windows) and should NOT be expected to drop capabilities they no longer need. Because of this, an extra pre-caution must be taken to ensure that nothing unsafe or untrusted will be run with elevated capabilities!

More about POSIX capabilities

[ChrysoliteAzalea]

• Capability bounding set and inheritable capabilities never change on execve

• If a process execves to a privileged binary (SUID/SGID/filecaps), it loses all ambient capabilities, and any capability will become permitted if it's set as permitted in filecaps and has is present in capability bounding set, OR if it's inheritable for the process and set as inheritable in filecaps. If "effective" is set in filecaps, then all permitted capabilites also become effective

• If a process execves to an ordinary binary, they keep their ambient capabilities and all their new permitted and effective capabilities will match their ambient capabilities

• SUID root binaries with no filecaps are presumed to have all capabilities set in their filecaps