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

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

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.

Tags:

Security

Kernel

Wine

Recent Posts