ptrace: allow restriction of ptrace scope
in [Kernel]
|
From: Kees Cook on 16 Jun 2010 20:50 On Wed, Jun 16, 2010 at 05:11:14PM -0700, Roland McGrath wrote: > > Though, honestly, just trying to get rid of PTRACE seems like the better > > place to spend time. > > Crushing irony of telling *me* this duly noted. ;-) > I am not really sure what deeply different set of security constraints > you envision on any other kind of new debugger interface that would be > any different for the concerns you've expressed, though. I haven't though too much about replacements, but it seems like having a way for processes to declare who/what can debug them is the way to go. I realize this is very close to MAC policy, but having this be more general-purpose seems valuable. Like, a different version of PTRACE_TRACEME, something like PTRACE_BY_YOU. Imagined example with total lack of error checking and invalid syntax... void segfault_handler(void) { pid = horrible_dbus_insanity("spawn a debugger"); prctl(PR_SET_DEBUGGER, pid); } PTRACE_TRACEME would be effectively the same as: void segfault_handler(void) { if (pid = fork()) { execl(debugger,getppid()); exit(1); } else { prctl(PR_SET_DEBUGGER, pid); } } > > > I suspect you really want to test same_thread_group(walker, current). > > > You don't actually mean to rule out a debugger that forks children with > > > one thread and calls ptrace with another, do you? > > > > Won't they ultimately have the same parent, though? > > Sure, those debugger threads will have the same parent, such as the shell > that spawned the debugger. But your "security" check is that the caller of > ptrace is a direct ancestor of the tracee. The ancestry of that ptrace > caller is immaterial. Ah right, sorry, I was being too literal (thought in your example the parent didn't fork a debugger and called ptrace on its children). Right, this would probably solve the Chrome case, but not KDE, which seems to fork the crash handler from very far away. I haven't looked too closely there yet. -Kees -- Kees Cook Ubuntu Security Team -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Morris on 17 Jun 2010 09:50 On Wed, 16 Jun 2010, Kees Cook wrote: [Note: it would be useful to cc: the LSM list on security discussions] > Certainly. PTRACE can already be confined by SELinux and AppArmor. I'm > looking for a general approach that doesn't require a system builder to > create MAC policies for unknown software. I want to define a common core > behavior. > > > And even if you don't care about using the same security stuff the rest > > of the world is using to solve the problem this like the other half baked > > stuff you posted for links belongs as a security module. > > The LSM isn't stackable, so I can't put it there and choose this and > SELinux (for the case of software-without-a-policy). SELinux already supports a global switch for ptrace via the allow_ptrace boolean. You don't need to write any policy, just set it to 0. Global behavior can be further customized and refined (e.g. create a generic policy module for apps without an existing policy, which allows everything except things like ptrace and dangerous symlinks). SELinux users would not need the other LSM, and stacking is thus not required. - James -- James Morris <jmorris(a)namei.org> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kees Cook on 17 Jun 2010 13:10 Hi, On Thu, Jun 17, 2010 at 05:29:53AM -0700, Eric W. Biederman wrote: > Kees Cook <kees.cook(a)canonical.com> writes: > > running state of any of their processes. For example, if one application > > (e.g. Pidgin) was compromised, it would be possible for an attacker to > > attach to other running processes (e.g. Firefox, SSH sessions, GPG agent, > > etc) to extract additional credentials and continue to expand the scope > > of their attack without resorting to user-assisted phishing. > > This is ineffective. As an attacker after I gain access to a users > system on ubuntu I can wait around until a package gets an update, > and then run sudo and gain the power to do whatever I want. I doesn't stop phishing, correct. But it does stop immediate expansion of an attack using already-existing credentials. > Either that or I can inject something nasty into the suid pulse-audio. Hmm? $ ls -la /usr/bin/pulseaudio -rwxr-xr-x 1 root root 71712 2010-06-10 11:59 /usr/bin/pulseaudio But I take your meaning to be "can still exploit other vulnerabilities". That'll always be true, but that's why I'm looking to make the attack surface smaller. > I tell you what. If you really want something effective, help Serge > and I finish getting the cross namespace issues fixed for the user > namespace. When complete, it will possible for an unprivileged process > to create a new one, and since kernel capabilities along with everything > else will be local to it, running pidgin, or firefox, or another network > facing potentially buggy application in such a namespace will ensure that > even if the process is compromised it won't have privileges to ptrace another > process or do much else on the system. It sounds pretty good, but isolating desktop applications is no simple task. They tend to like to have free reign over a user's entire home directory. But I think that's a bit of a tangent. That said, I'd like to know more; where can I find details? I'm all for better separations. In fact, I'd like to see /proc/sys using caps instead of DAC so that containers mounting /proc can't fiddle with the entire system. Has anyone done anything with this? It seems like it's only seen sporadic attention (e.g. my patch to test CAP_SYS_RAWIO for changing mmap_min_addr). I would assume there are others that need a similar protection? -Kees -- Kees Cook Ubuntu Security Team -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kees Cook on 17 Jun 2010 13:10 Hi James, On Thu, Jun 17, 2010 at 11:45:42PM +1000, James Morris wrote: > On Wed, 16 Jun 2010, Kees Cook wrote: > > [Note: it would be useful to cc: the LSM list on security discussions] Sorry, I was blindly using get_maintainer output. > > Certainly. PTRACE can already be confined by SELinux and AppArmor. I'm > > looking for a general approach that doesn't require a system builder to > > create MAC policies for unknown software. I want to define a common core > > behavior. > > > > > And even if you don't care about using the same security stuff the rest > > > of the world is using to solve the problem this like the other half baked > > > stuff you posted for links belongs as a security module. > > > > The LSM isn't stackable, so I can't put it there and choose this and > > SELinux (for the case of software-without-a-policy). > > SELinux already supports a global switch for ptrace via the allow_ptrace > boolean. You don't need to write any policy, just set it to 0. > > Global behavior can be further customized and refined (e.g. create a > generic policy module for apps without an existing policy, which allows > everything except things like ptrace and dangerous symlinks). > > SELinux users would not need the other LSM, and stacking is thus not > required. But if a user wants to disable ptrace using the SELinux LSM and then also disable sticky-symlinks via the ItsHideous LSM, they're out of luck. -Kees -- Kees Cook Ubuntu Security Team -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 17 Jun 2010 16:50
Kees Cook <kees.cook(a)canonical.com> writes: > Hi, > > On Thu, Jun 17, 2010 at 05:29:53AM -0700, Eric W. Biederman wrote: >> Kees Cook <kees.cook(a)canonical.com> writes: >> > running state of any of their processes. For example, if one application >> > (e.g. Pidgin) was compromised, it would be possible for an attacker to >> > attach to other running processes (e.g. Firefox, SSH sessions, GPG agent, >> > etc) to extract additional credentials and continue to expand the scope >> > of their attack without resorting to user-assisted phishing. >> >> This is ineffective. As an attacker after I gain access to a users >> system on ubuntu I can wait around until a package gets an update, >> and then run sudo and gain the power to do whatever I want. > > I doesn't stop phishing, correct. But it does stop immediate expansion of > an attack using already-existing credentials. sudo last I checked caches your password for a couple of seconds. So if you can probe the system to see when those couple of seconds are. >> Either that or I can inject something nasty into the suid pulse-audio. > > Hmm? > > $ ls -la /usr/bin/pulseaudio > -rwxr-xr-x 1 root root 71712 2010-06-10 11:59 /usr/bin/pulseaudio > > But I take your meaning to be "can still exploit other vulnerabilities". > That'll always be true, but that's why I'm looking to make the attack > surface smaller. Yes. Apparently pulseaudio has been fixed recently. >> I tell you what. If you really want something effective, help Serge >> and I finish getting the cross namespace issues fixed for the user >> namespace. When complete, it will possible for an unprivileged process >> to create a new one, and since kernel capabilities along with everything >> else will be local to it, running pidgin, or firefox, or another network >> facing potentially buggy application in such a namespace will ensure that >> even if the process is compromised it won't have privileges to ptrace another >> process or do much else on the system. > > It sounds pretty good, but isolating desktop applications is no simple > task. They tend to like to have free reign over a user's entire home > directory. But I think that's a bit of a tangent. That said, I'd like to > know more; where can I find details? The archives of the containers list. https://lists.linux-foundation.org/pipermail/containers/ or just looking. > I'm all for better separations. In fact, I'd like to see /proc/sys using > caps instead of DAC so that containers mounting /proc can't fiddle with the > entire system. Has anyone done anything with this? It seems like it's > only seen sporadic attention (e.g. my patch to test CAP_SYS_RAWIO for > changing mmap_min_addr). Ugh. CAP_SYS_RAWIO???? That certainly does not feel like the proper capability there. Which is among the reason I'm not a particular fan of capabilities. > I would assume there are others that need a similar protection? Let me quickly summarize the plan. The current implementation of the user_namespace is not much more than a place holder for what should be implemented. We may want to rename the user_namespace to the security credentials namespace when we are done. All uids, gids, capabilities comparisons should change from. if ( uid1 == uid2 ) to if ((user_ns1 == user_ns2) && uid1 == uid2). Somewhere Serge has a git tree where he started making the capabilities tests user_namespace local. Which means that when you create a process that does not share the current user_namespace you will get a full set of capabilities relative to the current user_namespace. The tricky bits are: - Working through the vfs logic, so that filesystems can be aware of multiple user namespaces and can do what best suits them when presented with a DAC security test. proc will need to become uid namespace aware, different files will become user namespace aware. Things like /proc/sys/ will be default stay in the same user_namespace and root in other user namespaces will only get world permissions when accessing files. - Correctly implementing and using ns_capable. Which makes the capabilities caparison hierarchical. A few key capability comparisons like CAP_NET_ADMIN will gradually be switched from a global capability comparison to a local one. If you are inside a user_namespace your capabilities will only be good for manipulating other objects (like the network namespace) that you have created after you entered the user namespace, other capability checks will fail because they will require the global capability namespace. The cute detail is that if you are not in a user namespace but are the creator of that user_namespace you will be treated for the purposes of security checks as having all capabilities that user_namespace posses. Which will allow important things like the ability to kill your children in a child user_namespace. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |