What is the 'ptrace_scope' workaround for Wine programs and are there any risks?

Question

To run certain Windows programs in WINE you need to this workaround:

echo 0|sudo tee /proc/sys/kernel/yama/ptrace_scope

According to the support websites, this is due to a bug in the Ubuntu kernel that prevents ptrace and WINE playing well together.

Using the above command you set the ptrace to 0 which according the research I've done(don't ask me which websites, I have seem a lot of them), ptrace has to do with the interactions between programs. The 0 setting is more permissive than the 1.

I have to assume that there was a good reason Ubuntu wanted the ptrace=1 so this leads me back to the short form of the question.

Are there any risks involved in setting ptrace=0. Lower security? problems debugging? any others that I haven't thought of???

P.S. for anybody reading this that wonders what the bug causes, the Windows programs will fail to open at all, in the System Monitor you will see many instances of the program trying to open and then they will eventually all quit and if you run the progam for the terminal you will get an error that tells you that the maximum number of program instances has been reached.

Answer 1

Short answer: no practical danger yet, but read on for a better way...

---

What's this ptrace thing anyway?

this is due to a bug in the Ubuntu kernel that prevents ptrace and WINE playing well together.

• No, ptrace protection is a deliberate kernel security measure first introduced around Ubuntu 10.10. It's not a bug, and so isn't going to be "fixed".

• In simple terms, the default ptrace_scope value of 1 blocks one process from examining and modifying another process unless the second process (child) was started by the first process (parent).

• This can cause problems with some programs under Wine because of the way wineserver provides "Windows Services" to these programs.

What are the risks in setting ptrace_scope to 0?

• This restores the old behavior where one process can "trace" another process, even if there is no parent-child relationship.

• In theory, a piece of malware can use this to harm you/your computer; e.g. it can attach to Firefox and log all of your URLs/passwords, etc. In practice this is extremely unlikely unless you blindly install binary debs from random sites, etc.

• As far as debugging goes, the 0 settings is in fact required for gdb, strace, etc. to attach to non-children unless you run them with elevated privileges (sudo).

What are the problems with the workaround?

• The workaround is somewhat problematic because ptrace_scope is a global value, and while it's set to 0, all processes on your system are exempt from the non-child restriction.
• If you use the workaround, put it in a simple bash script that enables it, runs your Windows program and then disables (sets to 1) on exit.
  • DO NOT make ptrace_scope world-writable (666) as the forum post recommends -- that is a huge security risk because now any process can change it at will!

Is there a better solution?

• A better solution which is more secure and does not require repetitively modifying ptrace_scope is to grant Wineserver ptrace capabilities.

  • In a terminal:

    sudo apt-get install libcap2-bin 
    sudo setcap cap_sys_ptrace=eip /usr/bin/wineserver
    sudo setcap cap_sys_ptrace=eip /usr/bin/wine-preloader
    

  • This exempts the wineserver and wine-preloader binaries from the non-child ptrace restriction, and allows them to ptrace any process.

  • It only needs to be done once, and is safer because these binaries are usually from a trusted source - the official repositories or the official Wine PPA, so they aren't going to be malware.

If you're using Crossover

Install libcap2:

sudo apt-get install libcap2-bin;

Then, add an exception for Crossover:

sudo setcap cap_sys_ptrace=eip /opt/cxoffice/bin/wineserver;
sudo setcap cap_sys_ptrace=eip /opt/cxoffice/bin/wine-preloader;

Finally, add its libraries to ld.so.conf (or you will get "error while loading shared libraries: libwine.so.1: cannot open shared object file: No such file or directory"):

echo /opt/cxoffice/lib/ | sudo tee /etc/ld.so.conf.d/crossover.conf
sudo /sbin/ldconfig

Answer 2

In the ubuntuforums.org I got an answer with the following link

https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection

here is the paste from the link(with my emphasis added)

As Linux grows in popularity, it will become a growing target for malware. One particularly troubling weakness of the Linux process interfaces is that a single user is able to examine the memory and running state of any of their processes. For example, if one application (e.g. firefox) was compromised, it would be possible for an attacker to attach to other running processes (e.g. gpg-agent) to extract additional credentials and continue to expand the scope of their attack.

This is not a theoretical problem. SSH session hijacking and even arbitrary code injection is fully possible if ptrace is allowed normally.

For a solution, some applications use prctl() to specifically disallow such ptrace attachment (e.g. ssh-agent). A more general solution is to only allow ptrace directly from a parent to a child process (i.e. direct gdb and strace still work), or as the root user (i.e. gdb BIN PID, and strace -p PID still work as root).

This behavior is controlled via the /proc/sys/kernel/yama/ptrace_scope sysctl value. The default is "1" to block non-child ptrace. A value of "0" restores the prior more permissive behavior, which may be more appropriate for some development systems and servers with only admin accounts. Using "sudo" can also grant temporarily ptrace permissions via the CAP_SYS_PTRACE capability, though this method allows the ptrace of any process.

So I guess the short answer would be that it's less secure but the likely hood of a personal computer coming under those kinds of attacks would be pretty slim.

Answer 3

UPDATE The above instructions:

sudo setcap cap_sys_ptrace=eip /opt/cxoffice/bin/wineserver;
sudo setcap cap_sys_ptrace=eip /opt/cxoffice/bin/wine-preloader;

does not work as of 9/15/2018 on Ubuntu 18.04.1 and PlayOnLinux v.4.2.12 using the latest stable version Wine which is v.3.0.1 libcap2 was already installed.

The error message in Gnome Terminal is as follows:

Failed to set capabilities on file `/usr/bin/wineserver' (Invalid argument)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file

Not sure what that means.....but thought I'd put it out there for anybody to interpret and maybe have a new, workable solution.

Thanks.

Answer 4

On Ubuntu 19.10 /usr/bin/wineserver and /usr/bin/wine-preloader are actually symbolic links not files. This probably applies to 18.04 as well. I saw the following solution on a different post, that I cannot find anymore. Try this instead:

sudo setcap cap_sys_ptrace=eip "$(readlink -f "/usr/bin/wineserver")"
sudo setcap cap_sys_ptrace=eip "$(readlink -f "/usr/bin/wine-preloader")"

Depending on which wine package you're using, you have to add either something like: echo /opt/wine-stable/lib/ | sudo tee /etc/ld.so.conf.d/wine.conf or: echo /opt/wine-staging/lib/ | sudo tee /etc/ld.so.conf.d/wine.conf followed by: sudo /sbin/ldconfig