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

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.

Solution 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

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