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

[WineHQ Bugzilla]

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

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

-- 
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.