[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 #10 from oiaohm <oiaohm at 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.

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