Previous Entry Share Next Entry
Fedora 17 New SELinux Feature part I - deny_ptrace
The deny_ptrace feature allows an administrator to toggle the ability of processes on the computer system from examining other processes on the system, including user processes.   It can even block processes running as root.

Most people do not realize that any program they run can examine the memory of any other process run by them.  Meaning the computer game you are running on your desktop can watch everything going on in Firefox or a programs like pwsafe or kinit or other program that attempts to hide passwords..

SELinux defines this access as ptrace and sys_ptrace.  These accesses allow one process to read the memory of another process.   ptrace allows developers and administrators to debug how a process is running using tools like strace, ptrace and gdb.    You can even use gdb (GNU Debugger) to manipulate another process running memory and environment. 

The problem is this is allowed by default. 

My wife does not debug programs, why is she allowed to debug them?  As a matter of fact most of the time, I am not debugging applications, so it would be more secure if we could disable it by default.

I created a feature for Fedora 17 called SELinuxDenyPtrace

Here is a youtube video demonstrating the SELinuxDenyPtrace feature.

Check it out.

  • 1
Hey Dan,

Thanks for the post. I'm running F16 (and CentOS 6 on some servers at work). They both have a boolean "allow_ptrace" and it's set "off" on both systems (F16, CentOS 6.2). But I can still strace other processes. What gives (I wish booleans were better documented...)?

David Klann

I originally thought about extending allow_ptrace, but I thought I had better just create a new boolean and remove the old. allow_ptrace only effected confined users. But since hardly anyone used confined users, I thought I needed a better way to describe the feature.

semanage boolean -l

Gives you a description of what the booleans allow.

sesearch -A -C | grep deny_ptrace

Will give you an idea of what is allowed/denied depending on the settings of the deny_ptrace boolean.

Maybe, better, is to add the following booleans:
unconfined_may_ptrace on/off
rest_may_ptrace on/off

I assume doing this for every domain is way too much (for example: httpd_may_ptrace).

Well most confined domains should not have ptrace period.

We made some kernel changes that stopped generating ptrace AVC's when looking at /proc/PID, which allows us to cleanup lots of the policy to remove ptrace and sys_ptrace from almost all unconfined domains.

deny_ptrace main goal is to take this away from the unconfined_t domain, since most users login with the context.

Thanks for feature and for video, Daniel.

what about a trace domain?

Just a thought:
If you disable ptrace in all domains except for a restricted trace domain which your debuggers run as (maybe limit write, etc) and only allow transition to this domain from a programer unconfined domain which would otherwise be identical to your user unconfined domain this might accomplish what you want with fewer knobs. Although your uber programmers may want a knob for writing debuggers.

Re: what about a trace domain?

I actually think that would be more difficult to do then just have the boolean. Since I would be by default having all users as unconfined_t then a programmer would need to setup debugger_t or something like that.

> My wife does not debug programs, why is she allowed to debug them?

Dan, you are a damn control freak.

I gave up trying to push through your thick skull a simple idea that if you make security too tight, people will refuse to use it.

You still fail to get it.

People still disable SELinux as soon as they installed Fedora, because it makes their lives miserable.

Thank you for your support

  • 1

Log in

No account? Create an account