Log in

No account? Create an account

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.)

  • 1

Please leave unconfined unconfined

Please consider modifying deny_ptrace to leave unconfined unconfined:.

1. Consider a student taking a programming 101 course and just learning to use GDB. It's very hard to arrange things so that the information "there's this thing called SELinux booleans and you have to turn one off" reaches them.

2. Fedora / Red Hat currently does not have majority market share among applications developers on Unix like platforms. If gdb works out of the box on Mac OSX and Ubuntu but not on Fedora, things are not going to end well.

This is from a user that's been reading your blog for years and tries hard to help his friends leave SELinux in enforcing mode by spreading information about permissive domains and custom SELinux modules.

Why did you make deny_ptrace apply to unconfined when you have your two requirements?

Re: Please leave unconfined unconfined

1. Currently the ptrace access does not seem to apply to gdp PROGRAM. Only gdp -P PID, so for most students this would not be a problem.
Also I believe ubunto has a similar feature to turn off the ability to ptrace random processes.

Also I think turning off security for a small subsection of people who could easily adjust their machines or have the teacher adjust their machines is not a justification.

2. I don't believe turning on or off this boolean is going to effect the number of developers on Red Hat Platforms.

If deny_ptrace does not apply to unconfined_t it would be almost useless, since it would apply to a minority of of people using confined domains.

Re: Please leave unconfined unconfined

At least on my f17 install it denies even things like gdb ./helloworld where I start gdb on my own program I just wrote.

Turning it off, so that I can debug my own programs means globally allowing it also for things I don't want this to have this capability?

I do think it is going to effect developers on Fedora/Red at platform. Not every hackers is administrator on all machines/severs they have to work on. If they are not the administrator it will mean that by default they cannot write/compile/debug stuff normally on such a machine. And I wouldn't be surprised if this becomes a "security race" between the developer vs the administrator wanting/not wanting to allow ptrace globally.

You say "... hardly anyone used confined users...". What're the chances of getting a good tutorial on how to confine users and not break the system completely?

I will see about doing a screen cast on this next week. Now that I have learned how to do screen casts. There is pretty good documentation on this at access.redhat.com if you have RHEL.

Are you aware that DrKonqi (and I believe ABRT too) needs to be able to attach GDB to a process to obtain a backtrace for the bug report? Those are tools very much aimed at the end user (to report bugs to the developers), they need this permission, and the users are likely to be unwilling or even unable to reproduce the bug after changing SELinux rules.

Re: DrKonqi, ABRT etc.

This question bothered me all night, but today I came in and checked abrt policy and it does not need this access. Not sure why it does not but it has not had this access in RHEL6 and all Fedora's so I guess it does not use ptrace or sys_ptrace access.

One of the problems with defining a few domains that are allowed this acccess, like abrt, would allow an unconfined_t user to do

runcon -r system_r -t initrc_t -- runcon -t abrt_t /bin/strace.

Which means I have to come up with a domain that unconfined_t can not transition to, but systemd (init_t) can. Currently we allow unconfined_t to transition to initrc_t which is allowed to transition to all init domains.

But I will make this change in policy and define a new interface init_systemd_domain() Which will only allow init_t to transition to a domain if the deny_ptrace boolean is turned on.

Thanks for your comment.

BTW I do not know what DrKongi is, is it in fedora?

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.

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.

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.

As a random thought, how feasible would it be a specific warning included in common ptrace users (eg, gdb) if you use, eg, "gdb -P PID" and it fails to attach but all the "normal" permission checks pass (eg, same userid, etc). A "this could be due to ptrace being blocked on unconfined users; see ..." type warning.

I suggest this having, earlier this week, in another context, spent a few minutes scratching my head wondering why something I was expecting not to be confined beyond normal unix permissions wasn't able to access file that its user appeared to be able to access. So if one expects to be unconfined and isn't, then a warning that "maybe you're more confined than you thought" is valuable.


PS: I don't think just an AVC log is going to help the uneducated enough. If they don't know they're being restricted they might not think to look there (which is where I was; once I thought to check it was immediately obvious what the cause of my issue was).

Are you patching the ptrace-using apps?

Are you patching e.g. gdb, so that if the ptrace protection is turned on, and the ptrace fails, it can emit a helpful error message saying what the magic switch is?

Re: Are you patching the ptrace-using apps?

Great idea, I will open bugs on this and see if I can write a patch.

Support people love to get the output from strace. Often it's "strace program" but it's almost as common to do "strace -p". Doesn't "strace -f" also require attaching to a process in the same way that "strace -p" does?

You're making the system more secure, sure, but you're making the life of the support people rather harder as well.

Re: strace for support?

Yes. But support people will know how to turn off the feature. Users will not know how to turn it on.

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

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?

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.

  • 1