View Full Version : Risk Free WineHQ Installation & Usage

4th April 2017, 06:52 PM
Finally I finish this guide !

Preliminary notes:

1) This guide written in the aim to achieve maximum possible security & safety for installation & usage of WineHQ,

2) This guide not merely directed against risk of Windows viruses & malware, but it aimed to give protection against Linux specific viruses & malware that engineered to attach Linux depending on already installed WineHQ,

3) This guide not a theoretical approach, but a real guide already tested in reality by me on Fedora Linux 24 & 26 X64 Cinnamon edition installed really on hard disk,

4) This guide written specifically for Fedora Linux taking in considerations Fedora specific property,

5) This guide written specifically for WineHQ packages available in Fedora official repositories taking in considerations specific properties of these packages,

6) Inspite point (4) above, core of this guide is applied for any Linux distro after a few tweaks in regard of difference in certain commands & certain packages,

7) This guide tested for WineHQ not for PlayOnLinux,

8) Applying this guide on your Linux OS is totally on your owen responsibility. I'm not responsible for any damage to your software or hardware that could be happened due to trying this guide,

9) You MUST follow this guide step by step (skiping only steps that not fit your specific distro - a distro other than Fedora - or your specific DE - a DE other than Cinnamon or GNOME,

10) This guide does not include block WineHQ dependent application from connect to Internet & risks that could resulted from this. We considered installation of antivirus as a defense against this risk in our guide taking in consideration the fact that many user like to run Windows applications that need communications with Internet like chat & messenger applications ...... .

4th April 2017, 06:54 PM
Guide to Run WineHQ in Virus/Malware Risk Free Mode:

N.B: texts in RED point to names you are free to change into any thing that you like.

N.B: text in BLUE point to name & path of package specific to Cinnamon & GNOME DE.

I. Create New Isolated Secure User Account:

1) create new user account that you like to make WineHQ only run within it (let we call it "wineuser"):

sudo useradd -m -d /windows -s /bin/bash wineuser

unlock this account by creating a password for it:

sudo passwd wineuser

this new user has different home directory from your owner user account, but have working shell which able to gain root privilege.

2) disable of wineuser account from obtain root privilege by any way through the following:

a- disable sudo power for "wineuser":

This is already the default setting in Fedora, so no need to this step.

But for other distros: menu, system setting, Users & groups, select "wineuser", & make it out wheel group.

b- disable su power for any newly added standard user:

sudo vi /etc/pam.d/su then uncomment the following line:

#auth required pam_wheel.so use_uid then save & exit

N.B: we mean by uncomment the above line: removing # from it, so that it become:

auth required pam_wheel.so use_uid

c- be sure that SSH (if already installed on your PC) is disabled:

- to show state of SSH in brief (just active or not active):

$ systemctl is-active sshd.service

- if SSH active, then stop it permanently by:

sudo systemctl stop sshd.service

4- restart your PC & login to "wineuser"

II. block all GUIs that still can take root privilege when launched/accessed by "wineuser":

There are certain GUIs that still can get root privilege from within "wineuser" account in-spite disabling su & sudo power. On Fedora they achieve this via polkit. They vary depending on DE. These should be blocked from this power. Currently, on Fedora 24 Cinnamon DE, we have following GUIs to be blocked:

- Firewalld GUI (Firewall)

- Network Connections

- yumex-dnf (package manager)

- dnfdragora (package manager – not installed by default)

- "Users & Groups" in system setting

- lightdm-gtk-greeter-setting ("Login Windows" in system setting)

- "unlock" option of "Date & Time" in system setting

- gnome-software (software center – not installed by default)

A) To block all these – except gnome-software – :

- login to your owner user account

- use "setfacl" command to block "riskywork" group from using "PolicyKit Authentication Agent", name of which vary depending on DE. To locate this package run following commands:

for GNOME & Cinnamon DE
rpm -ql polkit-gnome

for KDE DE
rpm -ql polkit-kde

rpm -ql xfce-polkit

rpm -ql mate-polkit

On Cinnamon & GNOME DE of Fedora 26 it is "/usr/libexec/polkit-gnome-authentication-agent-1"

- run following commands:

sudo setfacl -m g:riskywork:--- /usr/libexec/polkit-gnome-authentication-agent-1

By above command, all users belong to "riskywork" group are unable to authenticate any GUIs asking for root privilege.

To get more security protection, run following additional commands:

sudo setfacl -m g:riskywork:--- $(which pkexec)

sudo setfacl -m g:riskywork:--- $(which pkttyagent)


- "pkexec" is graphical fromtend for PolicyKit. It allows an authorized user to execute PROGRAM as another user.

- "pkttyagent" is used to start a textual authentication agent for the subject specified by either --process or –system-bus-name.

- Other Linux distros. may use other tools like gksu, gksudo, kdesudo, kdesu, xdg-su, beesu instead of PolicyKit. These DO NOT need to be treated by "setfacl" command - see note 9 in post 2.

- GNOME software can not blocked by "setfacl" - usually not ask for root on installing a package.

B) To block "wineuser" from touch GNOME software center:

- login to your owner user account

- create new group, let we called "gscaccess":

sudo groupadd gscaccess

- change ownership of GNOME software binary 1st, then after, change it's right as following in sequence:

sudo chown root:gscaccess $(which gnome-software)

sudo chmod 750 $(which gnome-software)

- add your 1st user "owner" account, say "John", to group "gscaccess":

sudo usermod -a -G gscaccess john

- restart your PC

By this only "John" account able to launch/access "gnome-software" application.

[N.B: you can add other user accounts (other than account(s) allowed to use WineHQ) to "gscaccess" to make them able to use "gnome-software" application.]

C) It is recommended, also, to delete launchers of these GUIs from applications menu of "wineuser" account.

III. Install WineHQ & Limit it’s Use to "wineuser" account only:

- login to your owner user account

- create new group (to add "wineuser" to it). Let we called it "riskywork":

sudo groupadd riskywork

- install WineHQ

- install "winetricks" package (optional)

- restart your PC, login to your owner user account

- change ownership of WineHQ binary 1st, then after, change it's right as following in sequence:

sudo chown root:riskywork $(which wine)

sudo chmod 750 $(which wine)

- special for Fedora (due to Fedora specific "wine-desktop" package):

Ctl+H to show hidden files & folders, enter into your home directory then into ./local/share/applications, delete all wine .desktop files & all other wine related files, finally Ctl+H to unshow hidden files & folders

right click on application menu, click on "configure...", select "menu" tab, chose "menu editor" & use it to delete all wine related entries. Currently they are:

A\ under "Wine" entry:

~ Notepad

~ Regedit

~ Wine Boot

~ Wine Configuration

~ Wine File

~ Wine Help

~ Wine OLE View

~ Wine Software Uninstaller

~ Wine Wordpad

B\ under "Games" entry:

~ a game

C\ lastly, delete "Wine" parent entry from applications menu

- add "wineuser" to group "riskywork":

sudo usermod -a -G riskywork wineuser

or you can do this from GUI: system menu, system setting, administration, users & groups …….. .

(N.B: you can, by same way, created other accounts & add them to "riskywork" so as to use WineHQ by them.)

- restart your PC

IV. Install & Use Antivirus:

We need antivirus to avoid virus damage or modification of your files while being within "wineuser" home directory.

We have 2 options:

1) install a Windows OS antivirus within "wineuser" account, through WineHQ. It should be pure antivirus without firewall abilities to avoid constrictions with Linux Firewalld. At present available options:

- portable clamav (currently has no real time protection)

- COMODO free antivirus (has real time protection but it is closed source)

N.B: this approach less invasive & not consume your machine’s resource when you using your owner account where antivirus scan work only within home directory of "wine user" account).

N.B: that Windows OS other than clamav may recognize WineHQ elements as viruses.

2) Alternatively, you can install ordinary antivirus package from repositories from within your owner account. In this case, antivirus scan will work on all your OS.

You have to update your antivirus & scan home directory of "wineuser" every time before using to avoid virus damage or modify your files while being within "wineuser" home directory.

That is all ! Now it is like that you have 2 laptops in your single PC. When you like to use windows application, say PDF restriction removal to remove password limitations from a PDF, you should put your PDF in USB flash stick, enter to "wineuser" account, update antivirus, scan USB flash, use windows program to remove limitations from it, then log out "wineuser" account & log in to your ordinary account & store your PDF in your ordinary home directory & let viruses play in "wineuser" account home – if escape scan !!

IV. Safe removal of very dangerous virus or malware:

If you feel that you have very dangerous virus or malware within wineuser account activated by Wine, you can get rid from this risk by uninstalling WineHQ then delete "wineuser" account.

To uninstall WineHQ safely proceed as following:

- login to "wineuser" account

- delete wine prefix "./wine" from within "wineuser" account

- switch to your owner user account, then

- uninstall WineHQ by terminal or your package manager

- delete"wineuser" account by following command:

sudo userdel -r wineuser

- delete "riskywork" group

sudo groupdel riskywork

4th April 2017, 08:03 PM
Additional Notes:

1) command
sudo chown root:riskywork $(which wine) should applied before
sudo chmod 750 $(which wine) command. Otherwise you will be inforced to log in as root using "su" to achieve chown command – see bellow.

2) once you apply command "sudo chmod 750 $(which wine)", you will never be able to touch "wine" package (change it’s original permissions & ownership or restore them to their original states, …), unless you 1st log in as root by "su".

3) however, you are still able to update, remove "wine" package, from within your owner account, using "sudo" command.

4) if your Windows applications or games need to use "winetricks" package, do not to forget to install it BEFORE changing WineHQ binary's ownership & rights. If you are not sure about your need for this package, please install it BEFORE such change.

5) updating/upgrading "wine" package should never change it’s ownership & permission, so their should no need to repeat steps in this guide after updating/upgrading "wine".

6) for a cause or other, if "wine" package removed then re-installed, you should repeat following steps:

sudo chown root:riskywork $(which wine)

sudo chmod 750 $(which wine)

7) if you like to use SSH, then you have to block remote root access through it by editing it's file. This beyond the scope of this guide.

8) immediately after upgrading your Fedora into higher version, do not forget to repeat following step before 1st login into "wineuser" account:

disable su power for any newly added standard user:

sudo vi /etc/pam.d/su then uncomment the following line:

#auth required pam_wheel.so use_uid then save & exit

9) Other Linux distributions may use other tools like gksu, gksudo, kdesudo, kdesu, xdg-su, beesu instead of PolicyKit. These tools DO NOT NEED to be treated by "setfacl" command as described in section III in 1st post above, because they are merely front-ends for su/sudo &, thus, are useless when su/sudo already blocked .......
The situation with PolicyKit is different because the applications that using PolicyKit never run with privileges above those of the current user, but, they indirectly make requests of the PolicyKit daemon, which is the only program that runs as root. So, such application, can still get root privileges inspit-of blocking su & sudo, & for that we need to treat PolicyKit by "setfacl" command as described in section III in 1st post above.

5th April 2017, 03:06 PM
thanks a lot!