https://bugs.winehq.org/show_bug.cgi?id=48889
Bug ID: 48889 Summary: Debian packaging: set cap_net_raw to allow sendings ICMP packets Product: Packaging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-packages Assignee: wine-bugs@winehq.org Reporter: luca.boccassi@gmail.com CC: dimesio@earthlink.net, michael@fds-team.de, sebastian@fds-team.de Distribution: ---
The attached patch adds postints and a dependency on libcap-bin, so that wineserver, wine-loader and wine64-loader can get cap_net_raw added on installation. Some games need to be able to send ICMP packets for anti-cheat reasons - see https://appdb.winehq.org/objectManager.php?sClass=version&iId=31145 Adding cap_net_raw means they don't need to be ran as root to do that, which is obviously bad.
I regularly get kicked out of BF4 servers as the latency of my clients cannot be measured.
https://bugs.winehq.org/show_bug.cgi?id=48889
Luca Boccassi luca.boccassi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian
https://bugs.winehq.org/show_bug.cgi?id=48889
Luca Boccassi luca.boccassi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |luca.boccassi@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #1 from Luca Boccassi luca.boccassi@gmail.com --- Created attachment 66835 --> https://bugs.winehq.org/attachment.cgi?id=66835 Patch to add postinst to set cap_net_raw on installation
https://bugs.winehq.org/show_bug.cgi?id=48889
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be Severity|normal |enhancement
--- Comment #2 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
The issue is already known as bug 8332.
I understand the staged patchset from that bug is not sufficient for Battlefield 4, but it's nonetheless the same issue.
This bug is in fact a proposal for an alternate workaround.
I'll set this bug to 'enhancement' and place a note in bug 8332.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #3 from Luca Boccassi luca.boccassi@gmail.com --- If there's any concern I can change the patch to make it dependent on a debconf setting, so that it's not enabled by default, but it gets enabled on demand (but it has to be done only once per machine, so it's still convenient).
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #4 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Luca Boccassi from comment #3)
If there's any concern I can change the patch to make it dependent on a debconf setting, so that it's not enabled by default, but it gets enabled on demand (but it has to be done only once per machine, so it's still convenient).
I like that idea. My main concern has been about forcing this change on users who don't need and may not want it, and making it available but not on by default seems like a good way to balance the needs of both groups.
We would also need to update our wiki instructions for Debian and Ubuntu. What should they say?
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #5 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to Rosanne DiMesio from comment #4)
(In reply to Luca Boccassi from comment #3)
If there's any concern I can change the patch to make it dependent on a debconf setting, so that it's not enabled by default, but it gets enabled on demand (but it has to be done only once per machine, so it's still convenient).
I like that idea. My main concern has been about forcing this change on users who don't need and may not want it, and making it available but not on by default seems like a good way to balance the needs of both groups.
We would also need to update our wiki instructions for Debian and Ubuntu. What should they say?
Depends - do we want the question to be asked on every package installation, or to silently default to disable and require either a preseed or a one time manual intervention after installation?
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #6 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Silently default to disable, otherwise we'll get heap of people complaining that it ask a question about something they don't need.
People that need it will look for a way to fix their application and will find the instructions in the wiki/appdb/howto, or we'll tell them on the forums/bugzilla where to find them.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #7 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to Olivier F. R. Dierick from comment #6)
Hello,
Silently default to disable, otherwise we'll get heap of people complaining that it ask a question about something they don't need.
People that need it will look for a way to fix their application and will find the instructions in the wiki/appdb/howto, or we'll tell them on the forums/bugzilla where to find them.
Regards.
Ok, I'll send an updated patch in the next couple of days.
https://bugs.winehq.org/show_bug.cgi?id=48889
oiaohm oiaohm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oiaohm@gmail.com
--- Comment #8 from oiaohm oiaohm@gmail.com --- (In reply to Luca Boccassi from comment #7)
(In reply to Olivier F. R. Dierick from comment #6)
Hello,
Silently default to disable, otherwise we'll get heap of people complaining that it ask a question about something they don't need.
People that need it will look for a way to fix their application and will find the instructions in the wiki/appdb/howto, or we'll tell them on the forums/bugzilla where to find them.
Regards.
Ok, I'll send an updated patch in the next couple of days.
Really the current patch needs to be junked its simple wrong. The work around people are doing to run games is also major security wrong.
(In reply to Luca Boccassi from comment #5)
Depends - do we want the question to be asked on every package installation, or to silently default to disable and require either a preseed or a one time manual intervention after installation?
Sorry this is not fine grained enough really.
Having to enabled libcap2-bin into recommend should have been warning signs.
cap_net_raw is not just enabled ping its also for complete system wide packet capture and modification.
cap_net_raw as decided a long time ago not to default on wineserver or the loaders due to the security risks involved.
Really before should put cap_net_raw on any part of wine part of packaging you really do need means for wine loaders and wineserver to drop cap_net_raw for applications that don't in fact need it and most likely have a system wide configuration that need to be changes to allow the possibility.
https://www.systutorials.com/docs/linux/man/3-cap_drop_bound/ Yes there are functions to allow a application to drop the caps they don't need.
Basically this requires a lot more code than what you have done not to be dangerous.
Windows malware does run in wine. Give some windows malware cap_net_raw is really asking for ass kicking.
Please note wine loaders and wineserver don't come out the box with the means to bind to ports under 1024(CAP_NET_BIND_SERVICE) either due to the same reason it not security wise to hand capabilities out to any random application.
Your patch contains nothing to restrict the applications that get the cap_net_raw flag usage. If user does this themselves and their system gets nuked by malware is not the wine project problem. If wine packaging does this by default the way you have wine provided packages could end up flagged as malware as well because wine would be enabling malware out the box in a really dangerous way.
Yes it painful to be on the wrong side of a security setting. Changing that setting on everyone to make your live simpler can also mean those users suffer a hell load of pain. Particularly when its like cap_net_raw that is a highly powerful and highly dangerous permission you are playing with.
I am not saying that cap_net_raw could not be enabled on wine in future but you have not treated that flag with the respect it need and have not done the work adding what is required to limit access.
Manually having to turn the flag on should be warning. In the appdb people are not writing the warnings how dangerous cap_net_raw is either that you have now enabled every application you run with wine if they wished can completely capture all network traffic and send it any party the like because wine has no system to limit what applications get to use the capability or not due to it being a all on or all off option.
Up until this point no one has wanted to work though the effort of making this way more fine grained. Maybe Luca you will be the one to-do this.
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #9 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to oiaohm from comment #8)
(In reply to Luca Boccassi from comment #7)
(In reply to Olivier F. R. Dierick from comment #6)
Hello,
Silently default to disable, otherwise we'll get heap of people complaining that it ask a question about something they don't need.
People that need it will look for a way to fix their application and will find the instructions in the wiki/appdb/howto, or we'll tell them on the forums/bugzilla where to find them.
Regards.
Ok, I'll send an updated patch in the next couple of days.
Really the current patch needs to be junked its simple wrong. The work around people are doing to run games is also major security wrong.
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. If you have confidentiality requirements on a machine and you choose to install it, I'm afraid you already lost. 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.
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: this is about being able to occasionally run a couple of games, not production-critical workloads.
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.
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #11 from oiaohm oiaohm@gmail.com --- (In reply to Luca Boccassi from comment #9)
For some users, like yourself, adding net_raw might be a step too far - then you are of course free not to enable it.
Something I better say. Before me wine project use to run wine as root. I am the one who brought capabilities as the path to-do this stuff are dealing with users who had nuked their complete Linux install with windows malware.
Yes I am the one who wrote it into the FAQ not to run wine as root and provided the basic instructions to use capabilities.
So I have over a decade of support knowledge of what effects your change is going to-do. I am not some new person complain for no reason with no experience to back position up here.
When I introduced capabilities I was hoping it would at some point get fixed up properly. I am pick up less problems with people using capabilities than the past of using run as root but I am still see the problems of malware exploiting capabilities from time to time when users have enabled them.
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #12 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
(In reply to Luca Boccassi from comment #0)
I regularly get kicked out of BF4 servers as the latency of my clients cannot be measured.
May I ask you to subscribe to bug 8332 and attach a WINEDEBUG=+wininet debug trace of running BF4 (without CAP_NET_RAW and until you get kicked) to that bug? Instructions to get a debug trace can be found at point 10.1.2 there: https://wiki.winehq.org/FAQ#get_log
I don't know if it applies to wininet but make sure that the debug trace is clean of login credentials (Look for your usernames/passwords. If there are any, replace them with a few stars '*').
Regards.
https://bugs.winehq.org/show_bug.cgi?id=48889
Luca Boccassi luca.boccassi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #66835|0 |1 is obsolete| |
--- Comment #13 from Luca Boccassi luca.boccassi@gmail.com --- Created attachment 66861 --> https://bugs.winehq.org/attachment.cgi?id=66861 Patch to add debconf postinst to set cap_net_raw on installation
As promised, here's a new revision that adds a low-priority debconf for the setcap. It can be enabled either from one of the many GUI tools, by setting DEBIAN_PRIORITY=low when calling apt, or by preseeding:
echo -e "wine-staging-amd64 wine/setcaps boolean true\nwine-staging wine/setcaps boolean true\nwine-staging-i386 wine/setcaps boolean false" | debconf-set-selections
(if done after installation, then follow-up with dpkg-reconfigure wine-staging-amd64 wine-staging wine-staging-i386)
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #14 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to oiaohm from comment #10)
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.
Thanks for the (unsolicited) curriculum, but I'm afraid the only actual, real problem being ignored is that users are silently running a configuration that is unsafe, and that causes them to get their accounts banned, incurring in very real tangible and even monetary losses. So, in reality, the only software acting as malware on my machine right now is wine itself. Fortunately someone already documented this broken behaviour in the applications DB pages, to help limit the damage. Unfortunately the workarounds are not "sticky" due to the nature of packages and file-based capabilities - which means at best users could be pinning the versions and avoiding updates, at worst the malware-like behaviour gets reintroduced without notice. Trying to be a good citizen, I thought of sharing a more durable workaround that doesn't require pinning, is a one-time configuration and is still under the developers control.
Of course you are absolutely free to hold off and instead spend another 13 years (the original bug, linked earlier, was opened in 2007) looking for a perfect solution to all hypothetical problems - I wish you the of best luck in your endeavours.
In the meantime, I'll share another solution which, unlike the packaging changes, is 100% under the control of users, while still being a one-time change:
$ cat /etc/dpkg/dpkg.cfg.d/wine-setcap post-invoke=if { test "$DPKG_HOOK_ACTION" = configure; } && test -f /opt/wine-staging/bin/wine-preloader && ! /sbin/getcap /opt/wine-staging/bin/wine-preloader | grep -qs "cap_net_raw"; then /sbin/setcap "cap_net_raw=epi" /opt/wine-staging/bin/wine-preloader; fi post-invoke=if { test "$DPKG_HOOK_ACTION" = configure; } && test -f /opt/wine-staging/bin/wine64-preloader && ! /sbin/getcap /opt/wine-staging/bin/wine64-preloader | grep -qs "cap_net_raw"; then /sbin/setcap "cap_net_raw=epi" /opt/wine-staging/bin/wine64-preloader; fi post-invoke=if { test "$DPKG_HOOK_ACTION" = configure; } && test -f /opt/wine-staging/bin/wineserver && ! /sbin/getcap /opt/wine-staging/bin/wineserver | grep -qs "cap_net_raw"; then /sbin/setcap "cap_net_raw=epi" /opt/wine-staging/bin/wineserver; fi
Unfortunately dpkg hooks are rather blunt tools - they run on every single action for every single package, which is truly icky. But it still beats losing accounts and money.
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #15 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to Olivier F. R. Dierick from comment #12)
Hello,
(In reply to Luca Boccassi from comment #0)
I regularly get kicked out of BF4 servers as the latency of my clients cannot be measured.
May I ask you to subscribe to bug 8332 and attach a WINEDEBUG=+wininet debug trace of running BF4 (without CAP_NET_RAW and until you get kicked) to that bug? Instructions to get a debug trace can be found at point 10.1.2 there: https://wiki.winehq.org/FAQ#get_log
I don't know if it applies to wininet but make sure that the debug trace is clean of login credentials (Look for your usernames/passwords. If there are any, replace them with a few stars '*').
Regards.
Thanks for the suggestion, and I'm truly sorry, but due to the completely uncalled for aggressiveness of your colleague, I lost any and all interest in helping out on this any further. I've shared a revised patch with debconf integration since I stated earlier I would do so, and I'll share the dpkg hook on the application database - but given that works for me, that will be it. Thank you for your efforts in supporting and developing wine.
https://bugs.winehq.org/show_bug.cgi?id=48889
Luca Boccassi luca.boccassi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|luca.boccassi@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #16 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Luca Boccassi from comment #15)
Thanks for the suggestion, and I'm truly sorry, but due to the completely uncalled for aggressiveness of your colleague, I lost any and all interest in helping out on this any further. I've shared a revised patch with debconf integration since I stated earlier I would do so, and I'll share the dpkg hook on the application database - but given that works for me, that will be it. Thank you for your efforts in supporting and developing wine.
Hello,
You already did more than most by reporting the issue and actually providing something constructive to work with, so thank you anyway.
I've asked the Battlefield 4 AppDB maintainers to copy the instructions to the HowTo section.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #17 from oiaohm oiaohm@gmail.com --- (In reply to Luca Boccassi from comment #14)
Thanks for the (unsolicited) curriculum, but I'm afraid the only actual, real problem being ignored is that users are silently running a configuration that is unsafe, and that causes them to get their accounts banned, incurring in very real tangible and even monetary losses. So, in reality, the only software acting as malware on my machine right now is wine itself.
No this is you ignoring that there are a 100+ games out there with third party mods that will steal people crypto curreny and bank account information and so on if they are given this privillage.
So this is two groups of parties that risk losing money. Yes there is a group who is not your group who will lose money.
Fortunately someone already documented this broken behaviour in the applications DB pages, to help limit the damage. Unfortunately the workarounds are not "sticky" due to the nature of packages and file-based capabilities - which means at best users could be pinning the versions and avoiding updates, at worst the malware-like behaviour gets reintroduced without notice. Trying to be a good citizen, I thought of sharing a more durable workaround that doesn't require pinning, is a one-time configuration and is still under the developers control.
There is a more durable work around write a privillage script to start the program need capabilities using capsh
https://churchman.nl/2019/03/14/granting-capabilities-using-capsh/
File based capabilities are a sledge hammer that you don't have to use to achieve your ends. capsh route allows starting a bash shell with cap_net_raw and run wine from there and only that instance has cap_net_raw enabled.
What is documented on the appdb page is the most unstable solution and most unsafe solution that you have proceed to duplicate.
Thanks for the suggestion, and I'm truly sorry, but due to the completely uncalled for aggressiveness of your colleague, I lost any and all interest in helping out on this any further.
You are wrong is not uncalled for aggressiveness from me.
Sometimes when you are running into trouble repeatedly it sometimes because you and everyone else is going the wrong way.
Basically file capabilities are not sticking because you are using the wrong option.
Creating a script that could have a stick bit on it to use capsh to lift a single wine prefix up with raised capability is possible. This does not cause the other security problems.
Patching wine so it drops the capabilities on all bar listed wine prefix would achieve the same ends.
Then you have what you are doing that is a security mess with the two options you have tried.
Those who have been writing the stuff in the appdb have not understood what they were using.
The original instructions in the FAQ are old and capsh was not an option back then in most distributions. Yet since I have not updated no one else has and no one else has done the research on the options to set capabilities.
Anyone who did a little bit of homework would have come across the capsh option.
See your problem the complete time is fixable without. 1) changing packaging 2) using file capabilities.
So when you are going the wrong way not understand what you are using exactly why should I not be annoyed.
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #18 from Alexandre Julliard julliard@winehq.org --- (In reply to oiaohm from comment #17)
You are wrong is not uncalled for aggressiveness from me.
Yes it is. Please stop that.
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #19 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to Luca Boccassi from comment #14)
So, in reality, the only software acting as malware on my machine right now is wine itself.
On reflection, this hyperbole was unnecessary and way over the top, as malware usually implies intent, which is of course not the case here. I apologize.
https://bugs.winehq.org/show_bug.cgi?id=48889
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #20 from Rosanne DiMesio dimesio@earthlink.net --- This has been added to the 5.7 wine-devel and wine-staging packages. I plan to add it to the stable packages whenever 5.0.1 comes out, assuming no problems turn up. I've added instructions to the Debian and Ubuntu wiki pages, and the FAQ entry.
https://bugs.winehq.org/show_bug.cgi?id=48889
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Rosanne DiMesio dimesio@earthlink.net --- Closing fixed packaging enhancement request.
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #22 from oiaohm oiaohm@gmail.com --- (In reply to Rosanne DiMesio from comment #20)
This has been added to the 5.7 wine-devel and wine-staging packages. I plan to add it to the stable packages whenever 5.0.1 comes out, assuming no problems turn up. I've added instructions to the Debian and Ubuntu wiki pages, and the FAQ entry.
The problem here is could be a while before the worse issues turn up. The global alteration is problem. There have been handful of people who have done the old modification that have been caught by the security risk.
The does need at some point come the ability to set the caps in usage based on WINEPREFIX to take away the attack surface.
What been done is like half the fix.
https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #23 from Austin English austinenglish@gmail.com --- (In reply to oiaohm from comment #22)
(In reply to Rosanne DiMesio from comment #20)
This has been added to the 5.7 wine-devel and wine-staging packages. I plan to add it to the stable packages whenever 5.0.1 comes out, assuming no problems turn up. I've added instructions to the Debian and Ubuntu wiki pages, and the FAQ entry.
The problem here is could be a while before the worse issues turn up. The global alteration is problem. There have been handful of people who have done the old modification that have been caught by the security risk.
The does need at some point come the ability to set the caps in usage based on WINEPREFIX to take away the attack surface.
What been done is like half the fix.
That should go in its own report.
-
WineHQ Bugzilla