Preview of changes to the Security susbystem for 2.6.36
in [Kernel]
|
Prev: [PATCH v2] dmaengine: Driver for Topcliff PCH DMA controller
Next: [PATCH] block: move blk_register_queue() before uevent is send out
From: Christian Stroetmann on 2 Aug 2010 14:50 Aloha Serge; On the 02.08.2010 20:08, Serge E. Hallyn wrote: > Quoting Christian Stroetmann (stroetmann(a)ontolinux.com): > >> Aloha James, Aloha Kees; >> Ont the 02.08.2010 08:57, Kees Cook wrote: >> >>> On Mon, Aug 02, 2010 at 04:41:08PM +1000, James Morris wrote: >>> >>>> On Sun, 1 Aug 2010, Kees Cook wrote: >>>> >>>>> Well, at least I'll have something for my summit presentation again. >>>>> >>>>> On the other hand, it's rather hard for me to defend against a private NAK. >>>>> >> A private NAK against a company's developer's OK >> Where is the difference private and company? I thought that it >> doesn't matter who and what a developer is, and where she/he comes >> from. >> > That's not what private means in this case. A private nak is one made > in a private email, so that the list - and the submitter - can't see the > rationale. It is problematic because it doesn't really allow the other > party to address the objection. > > (No big deal - Christoph has since responded in public.) > > Sorry, but AFAIK the NAK by Christoph that I meant was written in a public e-mail with full context to the LSM mailing list some weeks ago around the end of June (23 June 2010?!) and I thought Kees meant this NAK. :D But thanks for trying to clearify the case. Sorry Kees, if you indeed meant with private NAK a NAK made in a private e-mail. Have fun Christian Stroetmann -- 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: Valdis.Kletnieks on 2 Aug 2010 15:00 On Mon, 02 Aug 2010 09:59:36 PDT, Kees Cook said: > > Al gave you some very clear advice how a the sticky check should be > > This is patently false. "Very clear advice" would have included actionable > instructions. He (and everyone else) has ignored my requests for > clarification[2]. If you see how the check should be implemented, please > send a patch demonstrating how. I would greatly prefer having these > protections in the VFS itself. You're overlooking step zero of Al's advice: First, *think* about the issue in a deep fashion, rather than a knee-jerk patch to fix one instance of the problem. > > done for symlinks (if we need it at all, which I tend to disagree with), > > I can see how one might disagree with it, but anyone who handles day-to-day > security threats understands this protection to be a clear and obvious > solution for the past decade. The problem is that although your patch closes *one set* of symlink attacks that has been traditionally a problem, it doesn't do a very good job of creating a conceptual model and then *really* dealing with the issue. That's the big distinction between SELinux, Tomoyo, Smack, and your proposal - they form a *model* of what's important to protect, and what actions need to be taken to *actually* protect them. They don't just apply one arbitrary rule that closes some attacks - they make an honest effort to deal with all variants of the attack, and other attacks that allow bypass, and so on. The reason people are worried that this might grow into a "large" LSM is that quite often, throwing in a bunch of ad-hoc rules may create *apparent* security, but not provide any *real* security. You yourself admit that Yama only closes one set of symlink attacks without addressing the general issue of symlinks, hard links, TOCTOU races, and a lot of *other* similar "the file you actually opened is not the one you intended to open" attacks. And the reason it doesn't address the general issue is because it lacks a security model. And the reason you're having so much trouble getting it into the tree is because if you're going to apply this at either the VFS or LSM layers, you need to address the *general* problem and not one ad-hoc variant of it. And quite frankly, the idea of this morphing into a "large" LSM containing a lot of ad-hoc rules scares most security people, because without a good conceptual model, it's hard to define if the security is in fact working, or what the problem is if it isn't working. > > and the ptrace check completely breaks crash handlers that we have > > in all kinds of applications. If you can get it into the main ptrace > > I've seen two so far. Both are addressed with a one line fix. And I would > stress that no other existing subsystem in the kernel can provide the same > level of control that my ptrace exception logic provides. SELinux cannot do > this. Quick question: Now is that "SELinux doesn't consider the added granularity important and doesn't bother doing it", or "SELinux can't do it *currently*", or "there are innate structural reasons why SELinux is by design unable to do it"? Note that it's a big difference, and it's dangerous for your cause to bring it up without understanding which it is, and why... > This advice is precisely counter to prior advise. It would seem that no one > knows how to handle these patches. I find it very simple; either: > - let me put them in an LSM that people can choose to enable > - help me get the patches into shape for the subsystems directly You're still missing the point: > [2] http://lkml.org/lkml/2010/6/4/44 You were told to go back and form an actual *security model*. What's important to protect? What attacks can be made against it? What syscalls are included in the forseeable attacks (hint - probably more than you think - if you're mediating symlink access, a bit of thought will show symlinks aren't the only problem you need to worry about to *actually* secure the resource).
From: Kees Cook on 3 Aug 2010 13:00 On Mon, Aug 02, 2010 at 02:51:13PM -0400, Valdis.Kletnieks(a)vt.edu wrote: > On Mon, 02 Aug 2010 09:59:36 PDT, Kees Cook said: > > > Al gave you some very clear advice how a the sticky check should be > > > > This is patently false. "Very clear advice" would have included actionable > > instructions. He (and everyone else) has ignored my requests for > > clarification[2]. If you see how the check should be implemented, please > > send a patch demonstrating how. I would greatly prefer having these > > protections in the VFS itself. > > You're overlooking step zero of Al's advice: First, *think* about the issue > in a deep fashion, rather than a knee-jerk patch to fix one instance of > the problem. I think this is unfair. This solution has been used for 15 years in other hardened kernel patches. It's not knee-jerk at all. Not fixing this is not getting the "good" for the sake of wanting the "perfect". > The problem is that although your patch closes *one set* of symlink attacks > that has been traditionally a problem, it doesn't do a very good job of > creating a conceptual model and then *really* dealing with the issue. That's > the big distinction between SELinux, Tomoyo, Smack, and your proposal - they > form a *model* of what's important to protect, and what actions need to be > taken to *actually* protect them. They don't just apply one arbitrary rule > that closes some attacks - they make an honest effort to deal with all > variants of the attack, and other attacks that allow bypass, and so on. Okay, thanks for this explanation of why people don't want Yama as an LSM. I disagree with the logic, but at least I understand the reasoning now. "Since Yama does not provide a security model, it cannot be an LSM." This then leaves a gap for people wanting to make small changes to the logic of how the kernel works without resorting to endlessly carrying a patchset. > The reason people are worried that this might grow into a "large" LSM is that > quite often, throwing in a bunch of ad-hoc rules may create *apparent* > security, but not provide any *real* security. You yourself admit that Yama I can accept this as a theoretical position, but it's not like I've suddenly invented some new unproven protection. Given a choice between fighting to have it be an LSM and fighting to have it in the VFS, I prefer the VFS, since I'm trying to fix a flaw in DAC. > only closes one set of symlink attacks without addressing the general issue of > symlinks, hard links, TOCTOU races, and a lot of *other* similar "the file you > actually opened is not the one you intended to open" attacks. And the reason it > doesn't address the general issue is because it lacks a security model. And > the reason you're having so much trouble getting it into the tree is because if > you're going to apply this at either the VFS or LSM layers, you need to address > the *general* problem and not one ad-hoc variant of it. Well, here we disagree. DAC is flawed, this fixes a giant class of security problems. The model is "fix what sticky means for symlinks" and "fix when hardlinks are created". :P > And quite frankly, the idea of this morphing into a "large" LSM containing a > lot of ad-hoc rules scares most security people, because without a good > conceptual model, it's hard to define if the security is in fact working, or > what the problem is if it isn't working. I have regression tests for all the Yama features. I can prove if it's working or not. > > I've seen two so far. Both are addressed with a one line fix. And I would > > stress that no other existing subsystem in the kernel can provide the same > > level of control that my ptrace exception logic provides. SELinux cannot do > > this. > > Quick question: Now is that "SELinux doesn't consider the added granularity > important and doesn't bother doing it", or "SELinux can't do it *currently*", > or "there are innate structural reasons why SELinux is by design unable to do > it"? Note that it's a big difference, and it's dangerous for your cause to > bring it up without understanding which it is, and why... I don't know the answer to this, but other people I've asked have said they didn't think it was possible. I would tend to agree since it requires an explicit action from the debugee. MAC is system-owner defined. This is programmer defined. I want my program to be able to declare that a single specific pid can PTRACE it and nothing else. Another example of programmer defined access control would be the ability to "give up" access to syscalls, a finer-grained version of SECCOMP. > You were told to go back and form an actual *security model*. What's important > to protect? What attacks can be made against it? What syscalls are included in > the forseeable attacks (hint - probably more than you think - if you're > mediating symlink access, a bit of thought will show symlinks aren't the only > problem you need to worry about to *actually* secure the resource). Cross-uid symlink following and cross-permission hardlink creation are flaws in DAC that lead to a large persistent class of ToCToU vulnerabilities that are trivially avoidable. It's been fixed for 15 years. I'm not exactly sure how to model this. We've discussed how shared /tmp is one aspect of the problem, but it's not the entire problem. We've discussed how per-user /tmp is untenable in the short-term, etc. This is a way to get there now while per-user /tmp is slowly adopted over the next 15 years. -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 3 Aug 2010 13:10 On Mon, Aug 02, 2010 at 07:33:26PM +0200, Christian Stroetmann wrote: > structure of the other LSMs, especially if it becomes large and in > this way important to be followed by only growing it with > functionalities taken from other security packages. If you say that > the way of the Yama LSM is the right way to do it in general, then > we don't need a new LSM like Yama, but a new LSM architecture. Well, trying to get these protections into mainline does seem to be demonstrating a need for some kind of security architecture that isn't LSM. As for chaining, I was considering introducing basic "first non-zero return code wins" chain of LSMs, but the chain could include only up to 1 LSM that implements the proc attr hook (though the prctl handler isn't non-zero but rather non-ENOSYS). -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 3 Aug 2010 13:10
Hi David, On Mon, Aug 02, 2010 at 02:34:21PM -0400, David P. Quigley wrote: > On Mon, 2010-08-02 at 09:59 -0700, Kees Cook wrote: > [...snip] > > > > I've seen two so far. Both are addressed with a one line fix. And I would > > stress that no other existing subsystem in the kernel can provide the same > > level of control that my ptrace exception logic provides. SELinux cannot do > > this. > > > > Would you mind explaining to me what you believe this patch can do that > SELinux can't? Based on what I read in the kconfig entry for the feature > and the subsequent exception patch I'm not seeing anything here that > SELinux can't do. If there is something we are missing I'd like to > understand it so we can make the decision on whether or not our ptrace > access control checks need to be modified. Sure thing. When looking at how PTRACE is used, it seemed clear that there were exactly 2 use-cases: - tracking children (either for monitoring or debugging) - in-memory crash handlers Allowing child-tracing was easy: this is discoverable through process ancestry. Doing the crash handlers is different, since the handler can come from anywhere. One thing that seemed common was that the crashing program would know which pid was going to attach to it, so if those programs declared to the kernel which pid is allowed to attach, then it could make an exception for it. I did not find a heuristic approach that the kernel could use to figure this out for itself (maybe I missed something). It seems to me that SELinux (and AppArmor and maybe others?) can declare general relationships of who can PTRACE who, etc, but nothing that specifically says "only _this_ instance". Instead of "the crash handler binary running as $identity can attach to program foo running as $identity", it is "the crash handler process specified by program foo at the time of the crash, can attach to foo", which is much more specific. If there's a way to do this already, I am genuinely interested to learn more about it. Perhaps I've grossly misunderstood something. -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/ |