Hide Forgot
it's possible to create files outside of the new mount namespace by requesting coredumps, and then letting abrt-hook-ccpp from core_pattern copy it to your working directory. Of course, abrt is not aware of mount namespaces, and copies it to the cwd in it's namespace and not yours. To reproduce: $ sandbox -M -t sandbox_x_t bash bash-4.2$ mkdir -p .gnome2/nautilus-scripts/ bash-4.2$ cd !$ cd .gnome2/nautilus-scripts/ bash-4.2$ ulimit -c unlimited bash-4.2$ sh -c 'kill -11 $$' bash-4.2$ exit exit $ ls -l .gnome2/nautilus-scripts/ total 180K -rwxr-x--x. 1 taviso taviso 151 Jun 19 11:22 compare* -rw-------. 1 taviso taviso 412K Jun 22 17:47 core.7300 I don't know if it's possible to exploit this, obviously an attacker has a lot of control over the contents of a coredump. I imagine there must be somewhere you can drop it with very relaxed parsing.
I suppose the easiest fix is preventing resource limit changes via selinux, but it would be nice if there was a way to tell abrt not to try and parse (potentially hostile) coredumps.
Tavis, did you do this in enforcing mode?
Yes, of course.
Seems strange since abrt_t is not allowed to write to this directory. I am just wondering what context actually wrote to the directory.
ls -lZ .gnome2/nautilus-scripts/core.7300
Dan, are you saying you can't reproduce the issue? $ ls -lZ core.2677 -rw-------. taviso taviso system_u:object_r:gnome_home_t:s0 core.2677
Have not tried. abrt will not install on my rawhide box, and I was able to recreate on my box with a nfs_t homedir, although my question still remains on what process creates/copies the core file. It must be a process running under the users UID. But outside the sandbox. Or abrt is executing setuid(dwalsh)?
Yep, it runs as root (it's invoked by the kernel via /proc/sys/kern/core_pattern), and then uses seteuid() to create the file.
Kernel guys Should this thing be running as the process label that created the failure?
I'm not familiar with abrtd's architecture and operation, but it sounds like it is ripe for abuse. Coredumps should be created by the process that triggered them so that the file is labeled in accordance with the process' security attributes. That is important for protecting the confidentiality of the process' state and for protecting other processes from reading maliciously crafted coredumps. If abrtd uses a model where the coredump is passed by pipe to a helper that sends it over some other mechanism (socket?) to a daemon that writes the file, then we lose all connection to the originator's security context and attributes. I suppose you could have the helper pass the context and have abrtd make use of that information, but it would be cleaner to just have the helper write the file in the first place.
Not sure I understand the abrt policy. Policy defines an abrt_helper_t domain (abrt_helper_exec_t type) to which all domains transition, but this is only applied by file_contexts to abrt-pyhook-helper and abrt-hook-python, which don't appear to exist. Meanwhile, abrt-hook-ccpp is what is actually present and invoked, but it is left in bin_t and thus runs in the caller's domain. What is the intent there? BTW, if you were more selective about who you allowed to connectto abrt_t, you could at least prevent the sandbox domains from connecting to the daemon entirely. That doesn't solve the general problem, but would avoid breaking out of the sandbox via this mechanism. Presently you allow all domains to connectto abrt_t:unix_stream_socket, which seems undesirable.
abrt-hook-ccpp creates the coredump, and it's run by kernel using overridden /proc/sys/kernel/core_pattern which contains: |/usr/libexec/abrt-hook-ccpp so it's not abrtd who writes the coredump, but abrt-hook-ccpp which I guess is run outside the sandbox. And btw, the hook doesn't communicate with abrtd at all.
Reading the source code of abrt-hook-ccpp and enabling auditing suggests otherwise.
If it is run by the kernel then it probably is run as kernel_t which can pretty much do what it wants.
Ok, my mistake about abort-hook-ccpp. Sorry; misinterpreted the data. If abrt-hook-ccpp is being run in the kernel's context, then that is a kernel bug. I'm surprised though; shouldn't it run with the credentials of the process that triggered the coredump.
I see - do_coredump() invokes the pattern via call_usermodehelper_fns() if using a pipe, else it directly opens the core file. But it isn't preserving namespace, credentials, etc via call_usermodehelper. That's a kernel bug, and not just for SELinux.
Looks like you intended to run it in abrt_helper_t based on your policy, but file_contexts needs to specify abrt_helper_exec_t for abrt-hook-ccpp in that case. That at least gets it out of kernel_t.
The kernel behavior was apparently known although contrary to the patch description that went into git, http://marc.info/?l=linux-kernel&m=115562193022577&w=2 At the least, we need abrt-hook-ccpp to be labeled and trigger a domain transition similar to modprobe / hotplug so that we can then define policy for the userspace handler separate from the kernel. This appears to have been the intent of abrt_helper_t, but it isn't being applied correctly. That's a policy bug. I think though that it would be reasonable to re-open discussion of whether the kernel behavior is correct. Do we really want to provide an escape hatch from any restrictions imposed on the process (chroot, namespace, SELinux, capabilities, ...) via a coredump? And do we really want different security semantics for a pipe core_pattern vs. a pathname core_pattern? If not, then that's a kernel bug.
Since RHEL 6.2 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.