https://bugs.winehq.org/show_bug.cgi?id=8332
--- Comment #25 from oiaohm oiaohm@gmail.com --- Sebastian Lackner
Using exec in Wine in general is not necessarily bad, but it would of course be better to have only one "ping service" running instead of one application for each request.
Kinda agree kinda don't. Yes less applications but there is a limit. One ping service per application is the valid limit but then it comes when will you stop the ping service.
Remember Linux, Freebsd and Solaris have per application security. I can talk way better about Linux.
So a global service for running ping shared between all wine applications is directly breaking the Posix world security models. Same with the set capability on the loader to fix things. Both are using a sledge hammer for what should be carefully done.
Wine project for a very long time has taken the point of view that posix security models can be disregarded.
Lets say I wish to individually cgroup wrap a Wine applications into individually name-spaces at the moment. Anything done by shared services for applications become problematic.
Binding to ports, pinging, sending network traffic these are all per applications things and need to operate per application .exe so items like Linux Security Modules(LSM:think Selinux, apparmor) and cgroups can in fact work.
There are other issues like Linux binfmt-misc not being supported properly. If binfmt-misc worked properly the "setcap cap_net_raw+epi" could have been put in the .exe file instead of the loader so be per application. This would mean that using environmental vars to set wine settings would have to mirrored in xattrs or a file pointed to by a xattr containing instructions for the loader to follow. binfmt is where the Linux kernel picks up file set capabilities. You will not find no caps set on any native Linux loader. getcap /lib/ld-linux.so.2 and on on will all return no cap set. So the fact that getcap on /usr/bin/wine-preloader on Linux at times returns capabilities set is in fact a bug coming from poor integration.
In fact there are important reasons why capabilities should not be set on loaders. A loader does not contain a predefined task. So granting capabilities to a loader is granting those capabilities to every application run by that loader so breaking the per application security model into bits.
I was the one who pointed out that setcap privilage could be used instead of just running as root. But truly its only minorally better than running the applications as root. There are ways using CAP_NET_RAW to perform a privilege escape by messing with traffic. CAP_NET_BIND_SERVICE also in some cases allows privilege escapes by for example overriding local ldap server with your own yes the cannot bind to under 1024 on Linux is a security restriction to protect core services from random applications replacing them. Almost Linux every capability provides a means to take control the system if it configured in attackable ways. So using setcap is truly a mother of a hack with very bad security ramifications. So neither of the Caps users of wine are having to set are harmless. Its more luck than good management that systems are not being hacked because of wine.
Poor integration with the host OS is a fairly major wine problem. Lot of windows does X so should wine without proper consideration that there might be 2 or 3 ways to achieve X and the other ways may fit the host OS security model way better.
Basically from my point calling a privileged executable/service to perform a ping from a Windows application running in wine should not be a fall back position it should be the default. This is what Linux and other posix applications do when they want ping data. Behaving like a native application demands it. Not breaking native OS security demands it. If wine is taking a path that is completely different to how a host native applications are expected todo it then its a hack and need to be serous-ally considered if this is anywhere near correct because the security risk are no joke.
Sorry for being blunt.
Sebastian Lackner I do like your patch better question does it work with http://bahai-education.org/ocean/ that this bug was opened with and is still the only associated application.(If it does it grounds to close this bug if the patch is applied then maybe other people will learn to associate their application with bugs effecting them)