Yama: add PTRACE exception tracking
in [Kernel]
|
Prev: x86: enlightenment for ticket spin locks - eliminate NOPs introduced by first patch
Next: [PATCH 2/3] AFS: Use i_generation not i_version for the vnode uniquifier [ver #2]
From: James Morris on 30 Jun 2010 21:40 On Wed, 30 Jun 2010, Christoph Hellwig wrote: > Err, no. This is just a very clear sign that your ptrace restrictions > were completely wrong to start with and break applications left, right > and center. Just get rid of it instead of letting workarounds for your > bad design creep into the core kernel and applications. Indeed, I wasn't aware that there were further aspects to this -- I thought it was a relatively simple case of restricting a problematic OS feature for heavily locked down systems. This is getting more complicated, with fine-grained security policy now being introduced, also with the need to modify applications. There are several existing LSMs with the ability to control ptrace, but as part of a system-wide, coherent, analyzable policy -- often in support of specific security models for which there is concrete user demand and benefit. If people won't use any of SELinux, Smack, Tomoyo or AppArmor, then I don't think providing an ad-hoc assortment of workarounds with no overall design is going to help them either. If LSMs need to call into common code in Yama, or even do lightweight chaining, that's one thing, but for Yama to evolve into yet another standalone security scheme, is something entirely different. - 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 1 Jul 2010 00:50 Hi James, On Thu, Jul 01, 2010 at 11:39:01AM +1000, James Morris wrote: > On Wed, 30 Jun 2010, Christoph Hellwig wrote: > > Err, no. This is just a very clear sign that your ptrace restrictions > > were completely wrong to start with and break applications left, right > > and center. Just get rid of it instead of letting workarounds for your > > bad design creep into the core kernel and applications. > > Indeed, I wasn't aware that there were further aspects to this -- I > thought it was a relatively simple case of restricting a problematic OS > feature for heavily locked down systems. That's certainly my intent, but PTRACE is kind of a nasty beast. > This is getting more complicated, with fine-grained security policy now > being introduced, also with the need to modify applications. Well, I'm trying to solve what I think is a core problem with PTRACE -- it is too permissive. I'm happy to look at it from other angles if it doesn't make sense for this kind of thing to live in Yama. I'm already very happy with the existing restrictions available in Yama. > There are several existing LSMs with the ability to control ptrace, but as > part of a system-wide, coherent, analyzable policy -- often in support of > specific security models for which there is concrete user demand and > benefit. Sure. I am curious, though, is there a way for SELinux (or maybe Smack, since it has more dynamic labels) to declare this kind of on-runtime PTRACE relationship? Maybe I overlooked some options for this. I didn't see any way for the kernel to intuit the relationship without the tracee specifically declaring which process could PTRACE it, though. Regardless of the method, I think userspace changes would be needed for this kind of thing. I spent a little time discussing this within Ubuntu[1]. > If LSMs need to call into common code in Yama, or even do lightweight > chaining, that's one thing, but for Yama to evolve into yet another > standalone security scheme, is something entirely different. I still think simple chaining is the way to go. I want to review the earlier discussions first (I think Serge said it was in 2004ish?) before I write up anything. There is, I think, one sticking point, which is /proc/self/attr/current, but beyond that, I think some simple reorganization of LSM initialization routines and a list that security_* walks would be sufficient. Thanks, -Kees [1] https://lists.ubuntu.com/archives/ubuntu-devel/2010-June/030939.html -- 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: Serge E. Hallyn on 1 Jul 2010 09:30 Quoting Kees Cook (kees.cook(a)canonical.com): > > This is getting more complicated, with fine-grained security policy now > > being introduced, also with the need to modify applications. > > Well, I'm trying to solve what I think is a core problem with PTRACE -- it > is too permissive. I'm happy to look at it from other angles if it doesn't > make sense for this kind of thing to live in Yama. I'm already very happy > with the existing restrictions available in Yama. I've been jumping from one conviction to another to yet another and back again on this. First off, if you consider PTRACE_PTRACEME, and just consider this a more finegrained targeted version of that, it doesn't seem all that gross. So maybe that's my fault for suggesting prctl as an easier-to-use in LSMs api, bc using a PTRACE_PTRACEDBY might just look cleaner. Still, you say 'ptrace is too permissive', but a rebuttal to that is that, in a DAC system, ptrace uses what credentials it knows of to authorize. *You* can make it more finegrained by not insisting on running everything as a single user. What you now are trying to do is find a new, natural relationship between tasks on a plain DAC system to provide finer-grained control. The one you picked - process ancestry - doesn't perfectly fit, so you add changes and make it less clean. The criticism of that is valid and needs to be discusssed. Adding new relationships between tasks is what LSMs do - based on the policy-defined relationships between the security tasks of the respective domains. And it feeld natural there - so it's natural for SELinux and apparmor to confine firefox to a domain that can't ptrace anything else (and maybe not itself). One q then is whether YAMA wants to provide task tracking of its own, or stack with apparmor. > > There are several existing LSMs with the ability to control ptrace, but as > > part of a system-wide, coherent, analyzable policy -- often in support of > > specific security models for which there is concrete user demand and > > benefit. > > Sure. I am curious, though, is there a way for SELinux (or maybe Smack, > since it has more dynamic labels) to declare this kind of on-runtime PTRACE > relationship? Maybe I overlooked some options for this. I didn't see any In SELinux, you could give a debugger or crash handler an unprivileged, but allowed-to-ptrace-the-main-app domain. > I still think simple chaining is the way to go. I want to review the > earlier discussions first (I think Serge said it was in 2004ish?) before I > write up anything. There is, I think, one sticking point, which is > /proc/self/attr/current, but beyond that, I think some simple > reorganization of LSM initialization routines and a list that security_* > walks would be sufficient. In the past, output results for each LSM were simply split by \n or a : or something, and input was prepended by the LSM name. -serge -- 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: Stephen Smalley on 1 Jul 2010 11:30 On Thu, 2010-07-01 at 08:20 -0500, Serge E. Hallyn wrote: > First off, if you consider PTRACE_PTRACEME, and just consider this a more > finegrained targeted version of that, it doesn't seem all that gross. So > maybe that's my fault for suggesting prctl as an easier-to-use in LSMs > api, bc using a PTRACE_PTRACEDBY might just look cleaner. TRACEME is an alternative mechanism (to ATTACH) for establishing a tracing relationship, not a mechanism for expressing policy over ATTACH requests. The prctl was solely for configuring (Yama-specific) policy. > Still, you say 'ptrace is too permissive', but a rebuttal to that is that, > in a DAC system, ptrace uses what credentials it knows of to authorize. > *You* can make it more finegrained by not insisting on running everything > as a single user. > > What you now are trying to do is find a new, natural relationship between > tasks on a plain DAC system to provide finer-grained control. The one you > picked - process ancestry - doesn't perfectly fit, so you add changes and > make it less clean. The criticism of that is valid and needs to be > discusssed. > > Adding new relationships between tasks is what LSMs do - based on the > policy-defined relationships between the security tasks of the respective > domains. And it feeld natural there - so it's natural for SELinux and > apparmor to confine firefox to a domain that can't ptrace anything else > (and maybe not itself). Or to express whatever ptrace relationships you want to allow, regardless of process ancestry. > One q then is whether YAMA wants to provide task tracking of its own, or > stack with apparmor. Last I looked, apparmor did not support any kind of fine-grained ptrace constraints, just a simple unconfined || same-profile || CAP_SYS_PTRACE check. Whereas SELinux lets you control it based on the particular domain pairing. > > > There are several existing LSMs with the ability to control ptrace, but as > > > part of a system-wide, coherent, analyzable policy -- often in support of > > > specific security models for which there is concrete user demand and > > > benefit. > > > > Sure. I am curious, though, is there a way for SELinux (or maybe Smack, > > since it has more dynamic labels) to declare this kind of on-runtime PTRACE > > relationship? Maybe I overlooked some options for this. I didn't see any > > In SELinux, you could give a debugger or crash handler an unprivileged, but > allowed-to-ptrace-the-main-app domain. Exactly. What we do not want to do is to have the applications configuring policy on the fly. > > I still think simple chaining is the way to go. I want to review the > > earlier discussions first (I think Serge said it was in 2004ish?) before I > > write up anything. There is, I think, one sticking point, which is > > /proc/self/attr/current, but beyond that, I think some simple > > reorganization of LSM initialization routines and a list that security_* > > walks would be sufficient. > > In the past, output results for each LSM were simply split by \n or a : > or something, and input was prepended by the LSM name. I think the final form of the stacker patches put each value on its own line with the module name in parentheses after it. But it required a compatibility hack for SELinux and ultimately I think a libselinux patch to support SELinux stacked with anything else that wanted to use /proc/self/attr. -- Stephen Smalley National Security Agency -- 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: Stephen Smalley on 1 Jul 2010 16:00
On Thu, 2010-07-01 at 14:41 -0500, Serge E. Hallyn wrote: > Quoting Kees Cook (kees.cook(a)canonical.com): > > > > I still think simple chaining is the way to go. I want to review the > > > > earlier discussions first (I think Serge said it was in 2004ish?) before I > > > > write up anything. There is, I think, one sticking point, which is > > > > /proc/self/attr/current, but beyond that, I think some simple > > > > reorganization of LSM initialization routines and a list that security_* > > > > walks would be sufficient. > > > > > > In the past, output results for each LSM were simply split by \n or a : > > > or something, and input was prepended by the LSM name. > > > > This doesn't appear to be true anymore. Looking at the fs/proc/base.c and > > security/selinux/hooks.c code, there is no checking for a prepended LSM > > name. Maybe that's the first chaining limitation -- you can't chain 2 LSMs > > that both declare setprocattr hooks. > > No no, Stephen and I were talking about in the stacker patchset, again > around 2004-2005. Never went upstream (per 2005 or 2006 ksummit > agreement). Patch series was also available from: http://sourceforge.net/projects/lsm-stacker/files/ Looks like it was last updated in 2006. -- Stephen Smalley National Security Agency -- 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/ |