LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 01-31-2013, 05:13 AM   #1
jewelthief
LQ Newbie
 
Registered: Oct 2012
Posts: 9

Rep: Reputation: Disabled
Disabling/Removing CAP_SYS_PTRACE capability on Red Hat 5.3


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.
 
Old 01-31-2013, 06:26 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,374
Blog Entries: 54

Rep: Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870
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.
 
Old 01-31-2013, 01:02 PM   #3
jewelthief
LQ Newbie
 
Registered: Oct 2012
Posts: 9

Original Poster
Rep: Reputation: Disabled
@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.
 
Old 02-01-2013, 07:44 AM   #4
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,211

Rep: Reputation: 572Reputation: 572Reputation: 572Reputation: 572Reputation: 572Reputation: 572
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.

Last edited by jpollard; 02-01-2013 at 07:51 AM.
 
Old 02-01-2013, 07:56 AM   #5
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,211

Rep: Reputation: 572Reputation: 572Reputation: 572Reputation: 572Reputation: 572Reputation: 572
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).
 
Old 02-01-2013, 12:05 PM   #6
jewelthief
LQ Newbie
 
Registered: Oct 2012
Posts: 9

Original Poster
Rep: Reputation: Disabled
@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.
 
Old 02-01-2013, 01:23 PM   #7
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,211

Rep: Reputation: 572Reputation: 572Reputation: 572Reputation: 572Reputation: 572Reputation: 572
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.
 
Old 02-03-2013, 12:52 AM   #8
jewelthief
LQ Newbie
 
Registered: Oct 2012
Posts: 9

Original Poster
Rep: Reputation: Disabled
Quote:
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.
 
Old 02-03-2013, 06:25 AM   #9
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,211

Rep: Reputation: 572Reputation: 572Reputation: 572Reputation: 572Reputation: 572Reputation: 572
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.
 
Old 02-03-2013, 06:34 AM   #10
jewelthief
LQ Newbie
 
Registered: Oct 2012
Posts: 9

Original Poster
Rep: Reputation: Disabled
Yes we are working on RHEL 5.3.
 
Old 02-03-2013, 07:53 AM   #11
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,374
Blog Entries: 54

Rep: Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870
Quote:
Originally Posted by jpollard View Post
The most recent EAL 2+ Linux system I can find is RHEL from 2007 (EL 5).
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.
 
Old 02-03-2013, 08:41 AM   #12
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,211

Rep: Reputation: 572Reputation: 572Reputation: 572Reputation: 572Reputation: 572Reputation: 572
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.
 
  


Reply

Tags
headers, kernel, kernel source, redhat


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Red Hat v5 disabling single user runlevel logan_the_wolverine Linux - Newbie 6 02-21-2012 02:48 AM
USB IRQ disabling issue with self-built Red Hat kernel lennyk Linux - Kernel 0 02-08-2011 08:48 AM
disabling interactive boot in Linux/Red Hat/ CentOS unix1adm Linux - General 4 02-12-2010 01:00 PM
Removing Red Hat vgd1 Linux - Newbie 9 05-06-2009 01:09 PM
Removing Hardware from Red Hat cbriscoejr Linux - Hardware 3 12-08-2004 06:39 PM


All times are GMT -5. The time now is 07:51 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration