https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #10 from oiaohm oiaohm@gmail.com ---
Thanks for the (unprompted) lecture on cap_net_raw, but we know how it works and what it does. The entire point of wine is to run untrusted, third-party, proprietary and closed-source binaries.
Really that has not been wine only objective. There is a reason why wine was never made sudo or capabilities out the box.
If you have confidentiality requirements on a machine and you choose to install it, I'm afraid you already lost.
Sorry no. Wine default security settings are designed so it does not have out the box means to effect all users on a system. So a system with confidentiality requirements running all wine stuff as a particular user in wine default configuration and that particular user does not have access to stuff wine is not going to cause a security hole.
For some users, like yourself, adding net_raw might be a step too far - then you are of course free not to enable it. I'm fine with having it off by default, that's not a concern really. It can even be a low priority debconf option, so nobody will see it unless they go look for it. Other users for whom the distinction is perfectly meaningless can instead choose to enable it and have working applications.
Really this is your ignoring the problem.
For some software it's worth going to extra steps and spend extra time to drop what's not needed at runtime, and much more. But let's face it, it's really not the case here:
I would disagree big time. The extra step need to be done to protect game users from themselves to at least some extent.
this is about being able to occasionally run a couple of games, not production-critical workloads.
Lets take closer note at what you wrote. The person is going to play a couple of games. Is likely all games they are going to play will require cap_net_raw enabled the answer is no.
Next question does malware in mods for games exist that that take advantage of the features cap_net_raw enabled to capture packets and to work around firewall the answer is yes.
I do not want to have to be doing wine support and have to explain to a person that they enabled this feature using the winehq provided package and this has caused a person private communication information to be stolen at worse resulting in their ID stolen. Sorry to say being kicked out of game is only minor annoyance compared to stolen ID. You need to take the risks of these capabilities way more serous-ally.
Yes I know it will be a lot of effort coding up and designing the correct stuff so capabilities can be dropped on particular wine prefixes and the like but this is really what need to happen.
There is a old saying. Path to hell is paved with good intentions. This applys a lot in this case you have good intentions of letting programs work without waking up for min that you are stepping over a highly dangerous line that should be a very narrow path for how todo it yet you are enabling a wide path.
Sorry to say if it hard for users to run games that required cap_net_raw and less users run those games there are less users at risk.
I would not have even complained if you had enable cap_net_raw on the wine core binaries and I saw patches so those binaries check a global configuration file like /etc/winesecruity for listed approved wineprefixs and if prefix was not listed the dropped the capability. Yes you can check if wine has any capability before processing that file.
Yes person wanting to run the games requiring extra privilege would have to still go out of there way to enable cap_net_raw on wineprefix by add it to the /etc/winesecurity and if it was done this way and cap_net_raw change would no longer be nuked when wine updated. It would also give those running multi different games the means to put games that don't need this privilege in one wine prefix and games that do in a different one so reducing the security risk.
Lot of games that require cap_net_raw don't allow third party mods so they are not a high risk of malware third party mods but there are a lot of games that don't require cap_net_raw that have a history of malware third party mods.
Basically I don't class have cap_net_raw enabled on wine as a step to far. I class it as a step to far to enable cap_net_raw uncontroled due to the malware that exists in the wild.
By the way cap_net_raw is not only used to make games work it also used for some productivity applications so their copy protection crap works. So your idea that is only people who are playing games who are going to use the feature you will enable is wrong. So you really need to lift the bar on the security requirement.
Problem is I see that I am going to be picking up the mess from this patch in #winehq on freenode in future from those enabling it without understanding what they are doing it. I have already seen a few caught out following the appdb directions I do not need to be seeing more.
Basically I have already seen real world examples that says what you are going to put into the package and make simpler to-do is a really bad idea. Remember I am not against doing it if you in the process fix the problem so that cap_net_raw and other capabilities you can enable on wine don't end up handed out globally that would fix 99.9 percent of the issue I am seeing. Of course you have the 0.1 where the user need to take more care when capabilities are enabled on wine and that 0.1 might justify printing out a text line in the log that its enabled so a person like me doing support knows it was enabled.
Sorry to say the current capabilities location with wine is basically invisable to use doing support until we ask questions.
Basically this area is more problematic than you are taking into account so far.