Hello!

I am only a programmer and not a system administrator so I am in need of help from you gurus on this matter.

I am writing an application and I dont want anyone to run ptrace on it. Our requirement is to disable the ptrace kernel capability altogether so no process can run ptrace system call in our operational environment.

I have googled it a bit and found lcap utility to remove kernel capabilities. I was successful in removing some kernel capabilties through lcap but removing CAP_SYS_PTRACE does not have any effect.

Output of lcap (without any switches) shows me that lcap does not support removing CAP_SYS_PTRACE on my system so I search it a bit and found out that I have to change the linux/capabilty.h and recompile the kernel. Here is the file for your reference:

http://sop.upv.es/lxr/http/source/in...?a=x86_64#L308

but I dont know what to change in that file so that I am able to remove CAP_SYS_PTRACE.

Any help would be appreciated.

Moved: This thread is more suitable in the Programming forum and has been moved accordingly to help your thread/question get the exposure it deserves.
*Before you continue I suggest you assess (explain?) the real reasons for wanting to do that, what control you (can not) exert over an environment, the risk / damage of anyone debugging the application, a cost / benefit analysis of that or other modifications and familiarize yourself with the anti-anti-ptrace side of things.

@unSpawn

Lets say that its a compulsion on us to restrict the process tracing capability in operational environment where our application will run. We'll provide the operational environment along with application.

The simple answer is that you can't.

CAP_SYS_PTRACE is only a flag used to control the ability to use the ptrace system call and limit it to processes owned by the user. With the flag set, ptrace can trace any program. With it clear, ptrace can only trace programs owned by the user.

The flag itself does nothing.

A longer answer, is maybe ... but it is up to the application.

What you are trying to do seems like you want to disable the ptrace system call. (http://serverfault.com/questions/285...on-rhel5-linux).

It isn't easy as it breaks a number of system tools (strace, and any debugging tools). It also is very hard to get right, and easy to have it look like it is working, when it really doesn't. Some versions of ssh have a ptrace blocking facility built in, and it went through about a years worth of debugging to get it right (and it made debugging of the blocking code VERY difficult to do).

As I recall, the way it worked was to deliberately invoke ptrace on the running process. A process already being ptraced (even if it is a no-operation) cannot be ptraced by another process (such as a debugger). It does mean that the ptraced process MUST be the parent of the process doing the tracing. That way, the parent process (the one being protected) can detect if the blocking process is terminated and can exit before a new ptrace can be activated.

This is not the designed use of the ptrace system call, but it can be done.

And you can't remove the ptrace system call itself - that requires a kernel modification and you can't prevent your customers from using any Linux kernel (and there is still the requirement that you distribute the source to your kernel modification).

@jpollard

Actually we are building an application that would meet FIPS140-2 standards and to get it accredited, FIPS specifies an assertion that operating system (where a cryptographic software would run) should provide mechanism to prevent process tracing. If strace or gdb cant run due to this then its no problem.

It is a problem if you can't release the system.

That is why I referred you to a process that attempts to prevent ptrace from working.

The problem is "and accredited". Even if you get it accredited, it would be useless if customers cannot use it, or it fails accreditation because the target environment cannot be controlled. If you can get away with it, you could always say "accredited if ptrace and core dumps are removed from the system". But that still doesn't prevent a kernel module from being able to dump memory (memory maps are available for the process, and an I/O always can dump resident memory... and there is always that USB controller attack that can dump any part of physical memory). The way I see it there are three things out of your control:

1. the actual hardware platform (no PC can be accredited due to the insecure design).
2. the OS environment (no OS can be accredited - just too expensive)
3. the user.

All that can be done is to make it "more difficult".

One of the things that is done when a problem occurs with an obscure error is to run strace on it to see where it is failing, or what it is attempting to access. So removing ptrace from the system is usually impractical (and you can't prevent the customer from running one with ptrace in it either).

Since no linux system I am aware of is accredited, accrediting a specific application doesn't follow... The first patch to the system breaks the accreditation.

Now, if you are running it on a fairly recent RH based system (WITH SELinux enforcing), you can define a role that prevents everyone (or in the usual configuration, except root), and assign that to the executable. When the application runs under that role, it can't be traced.

But that is not an accredited system either.

In all cases, tracing can always be done... not necessarily easily, but dumping the application core would be enough.

What I outlined would block the basic ptrace operation... but it can't prevent coredumps (though, like blocking ptrace, it should be possible to manage getting the processes ulimit changed internally to 0), and I don't think any implementation could be accredited... It really depends on the profile level you are trying to reach. And no, I haven't done it either - I was on the sideline of the ptrace blocking development, not part of its development.

Looking over the FIPS 140-2, the only level (IMHO) I think is achievable is level 1, and I believe a method to blocking ptrace would suffice for that.

No. Software modules can achieve FIPS level 2 and removing process tracing capability of EAL 2+ operating system is one of the assertions of FIPS 140-2 level 2 of software modules.

The most recent EAL 2+ Linux system I can find is RHEL from 2007 (EL 5).

So you have an approach that should work, though a bit awkward to implement.

Yes we are working on RHEL 5.3.

IIGC the most recent certification date for RHEL 5.3 is is Dec 23rd 2009 when it achieved CC EAL4+ : see CCEVS-VR-VID10338-2009 or the Red Hat Enterprise Linux Certification and Accreditation Tables.

I have now seen RHEL 6 given EAL4 last November. But in all cases it was "overall level 1".

The only way I know to block ptrace is the methods (having a ptrace previously set, or having a SELinux jail for the application to block anyone but the application) outlined above. And of the two, I know having the ptrace set works, but have not done anything with an SELinux jail for the purpose so I don't know how well that would work.

Any kernel modifications will break the RH EAL rating.