Dan Walsh's Blog

Got SELinux?

Previous Entry Add to Memories 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.)

Actually, I now realize why ABRT doesn't need this access: it doesn't attach to a running process, but to a core dump.

DrKonqi is KDE's crash handler. It is in Fedora, because it is part of kdelibs (libkdeui) and kde-runtime. All the KDE GUI apps use it. Unlike ABRT, it reports the bugs to KDE upstream's Bugzilla, which makes a lot more sense because they are the ones who have to fix the bugs anyway.

But DrKonqi works very differently from how ABRT works. This is how DrKonqi operates:
* KApplication in libkdeui installs a crash handler called KCrash. That crash handler intercepts SIGSEGV, SIGABRT etc., fires up an external drkonqi executable, then blocks the process.
* The drkonqi executable (in kde-runtime) brings up the DrKonqi UI, which displays some information passed on the command line and offers to report the bug and/or to restart the crashed application.
* There is a tab in the DrKonqi UI (and also a required step if you are going to report the bug to the developers) which produces a backtrace. To do so, DrKonqi attaches GDB to the crashed process (which the crash handler blocked, but did not terminate, so this is a real live process, not a core dump) and asks it for a backtrace.

So, in short, I believe everything other than disabling deny_ptrace by default WILL break DrKonqi! You cannot even use "a domain that unconfined_t can not transition to, but systemd (init_t) can" because DrKonqi is not started by systemd, but by the crashed application. (Well, to make things even more complicated, by default, DrKonqi is actually started by kdeinit4, which is started within the user startkde session, but any application can ask kdeinit4 to start anything, so if kdeinit4 can transition to something, the user effectively can, too. This is a hack KDE uses to have to load the KDE libraries into memory only once and always fork the process with those libraries already loaded.)

The easiest way to test DrKonqi is to install kwrite and to run:
kwrite &
killall -SIGABRT kwrite
This will be intercepted by DrKonqi (not ABRT, because KCrash intercepts the crash while the process is still live and triggers DrKonqi, so ABRT doesn't get a chance to see the crash, because ABRT triggers only when the process terminates and core dumps).

As far as I know, there are also other upstream projects using bug handlers which work like DrKonqi. ABRT is the only bug handler I know which uses core dumps. You are going to break all those bug handlers.

Re: DrKonqi, ABRT etc.


2012-02-03 05:05 pm (UTC)

THen I guess I would tell the DrKongi tool to disable the boolean. I still feel this is enough of a feature to allow most of gnome users and therefore most of Fedora users the ability to stop apps from examining other apps memory.

So first of all, it's called "DrKonqi" with a 'q' (lowercase 'Q'), it's named after "Konqi", the mascot of KDE and Konqueror.

DrKonqi is used by all apps built on the KDE Platform (kdelibs and related libraries), independently of the desktop environment you run it under. There are many users of GNOME and other non-KDE desktops using e.g. K3b, Kile etc. By breaking DrKonqi, you will break those applications' automated bug reporting and thus actively sabotage upstream's efforts to fix crash bugs. It is just not an acceptable default.

And how would we disable the boolean? I guess we could run setsebool in the KDE spin kickstart, but that would not help for all the users of kdelibs-based applications under other desktops, nor for KDE Plasma Workspace users installing from the DVD.

And finally, while DrKonqi is the one I'm familiar with, I'm fairly sure there are other crash reporting tools working the same way.

Re: DrKonqi, ABRT etc.


2012-02-03 06:21 pm (UTC)

Whatever rpm installs the DrKonqi functionality should check in its post install if the deny_ptrace is turned on and then disable it iff it is the initial install.

setsebool -P deny_ptrace 1

If any other package needs this functionality it could to the same, then each of us are happy.

You are viewing danwalsh