[Bug 48889] Debian packaging: set cap_net_raw to allow sendings ICMP packets

WineHQ Bugzilla wine-bugs at winehq.org
Tue Apr 7 02:47:34 CDT 2020


https://bugs.winehq.org/show_bug.cgi?id=48889

oiaohm <oiaohm at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |oiaohm at gmail.com

--- Comment #8 from oiaohm <oiaohm at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.



More information about the wine-bugs mailing list