Dan Walsh's Blog

Got SELinux?

Previous Entry Share Next Entry
More on deny_ptrace ...
This boolean brings into conflict two of my top goals with SELinux.

1. Make the system secure by default.

The problem with most security systems is NO ONE turns them on.  NO ONE increases the security of their system.
Now while these are exaggerations, I would bet you that 99 % of SELinux users never turn on confined users, or disable the unconfined module .  There are large numbers of people who run SELinux in permissive mode or even disabled.    If we shipped Fedora and RHEL with SELinux disabled, I would bet the number of people who would enable it would be infinitesimally small.    So when I add a feature, I always think about how it would help the vast majority of people.    Will this boolean make my Wife's computer more secure.

2. Keep the unconfined domain unconfined...

Read the blog for why uses expect things to just work, especially from their logged in accounts, especially if they are the admin.

Should deny_ptrace be on by default????

Well deny_ptrace actually confines the unconfined domain, so it conflicts with #2, but if I don't turn it on, for the most part people will not take advantage.  Most users would not see the benefit.  Right now I am going to turn it on by default (Of course I reserve the right to change my mind, or be beaten into submission.)  Any person who wants to disable it permanently can execute.

# setsebool -P deny_ptrace 0

Programmers and system admins if you get a "permission denied" or "Operation not supported" error with ptrace, strace or gdb, it is SELinux causing the problem, and if you need to debug a problem, you can turn the boolean on temporarily.

# setsebool deny_ptrace 0

And do your thing.

Since sysadmins and programmers understand Linux best, it would be easier for them to toggle the security feature.

Now some questions about this feature.

What happened to allow_ptrace boolean in RHEL versions and older Fedora's? 

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, and change its name.  I have removed allow_ptrace and now deny_ptrace will remove all ptrace, sys_ptrace that I know about from the system.

Does deny_ptrace guarantee no domains on my system can ptrace another domain? 

If you load a custom policy with an "allow XYZ self:process ptrace", this boolean will not effect it.  So it only effects actually policy shipped by Fedora or Red Hat.
deny_ptrace does not effect permissive domains,  or permissive mode (obviously),  so if you want to make sure no processes can execute ptrace, you need to disable permissive domains.

After you turn on the deny_ptrace boolean, you can check if any domains are still able to ptrace by executing

# sesearch  -A -C -p ptrace,sys_ptrace | grep -v ^D

What about separation between root and users?

Well SELinux does not know anything about UID users, so root and non root mean nothing to SELinux.  The only way to get this distinction is by setting up confined users and then say run as staff_t as non root and then transition to unconfined_t, or sysadm_t or a confined admin type.  But since hardly anyone uses confined users, this is not an option, if I want to make most computers more secure.

Could you add a bunch of booleans that allows us to turn on and off ptrace per confined domain?

Well this is not really necessary, since most confined domains can not ptrace now, or only could ptrace because of some bugs in the kernel that generated ptrace avc's when running the ps command as root or if a process examined the /proc/PID files of another process.    We have fixed these kernel issues and are removing most domains ability to ptrace permanently, Ie turning deny_ptrace off DOES not allow every domain the ability to ptrace, only a few select domains that we believe might need it.  (Really just user domains.)

Writing, compiling, running programs, but not debug them?


2012-04-08 08:18 am (UTC)

I was testing F17 just now and to be honest this feature seems not fully thought out. I do understand the intent. Don't allow firefox plugins to introspect on arbitrary other processes of the user on the machine. But this feature (if turned on by default) is a bit of a sledgehammer. I might not fully understand the subtleties of selinux, and what confined or unconfined users/processes are. But a normal user is allowed to write, compile and run their own programs. But now they need to have root privileges to be allowed to debug their own programs?

I love to deny ptrace (arbitrary process introspection) to things like firefox plugins, but having to disable this (and allow anything to use arbitrary ptrace calls) just to be allowed to debug my own programs seems a bit weird.

Can't this feature be made a little bit less rigid? So it can deny ptrace just for specific use cases, but allow it for normal users so they can at least debug their own programs?

Also it seems to not distinquish between introspection on arbitrary processes (strace -p, gdb -p) that use PTRACE_ATTACH, and "normal" debugging which uses PTRACE_ME. Is it ever necessary to disallow PTRACE_ME? https://bugzilla.redhat.com/show_bug.cgi?id=802072

Re: Writing, compiling, running programs, but not debug them?


2012-04-09 03:47 pm (UTC)

The PTRACE_ME Separation should be coming in the next kernel. Meaning this feature will not block

gdb /usr/bin/foobar, but will block gdb -p 1234.

We currently block mozilla plugins from ptrace by default in F17 with or without this feature.

Sadly I will have to turn off the boolean by default, because this is what I originally stated in the feature page which Fedora Approved. If we fix our other problems, I will request a feature to Fedora 18 to turn it on by default.

You are viewing danwalsh