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 3 Aug 2010 17:50 Hello everybody; On the 03.08.2010 18:50, Kees Cook wrote: > 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. > > I would say it in a different way: "Since Yama has as a security model a container that is field with functionality of other security packages that have a security model but are no LSMs, then instead of making a new LSM like Yama the LSM architecture should be overworked to make the whole security packages and implicitly their security models LSMs." >> 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 >> > To be honest, I don't think this is a reason. The reason I see is that a "large" LSM consisting of a thrown in bunch of ad-hoc rules may rule the structure of the security model of LSMs. > 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. > > But it was discussed that it should become at least an LSM. And it was found out that: 1. No new unproven protections have been invented. 2. The functionalities/features were taken out of other security packages that are no LSMs but (seem to) have a security model. 3. The question was not answered if the functionalities/features could be done by already existing LSMs (eg. SELinux). >> 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. > > That's out of context. The context was if the whole conceptual model with all of its features is working and not if every single feature of Yama is working. >>> 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 > > 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: Kees Cook on 3 Aug 2010 18:40 On Tue, Aug 03, 2010 at 05:38:20PM -0400, Valdis.Kletnieks(a)vt.edu wrote: > On Tue, 03 Aug 2010 09:50:10 PDT, Kees Cook said: > > > 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 fact that a patch for one case has been used for years doesn't mean > that it's a well thought out fix for the general case. Well, we clearly disagree on this point. :) > It will likely not be accepted as an in-tree LSM, especially given that currently > it's rather difficult to stack two LSM's - which means that if a site wants to > run Yama, it becomes unable to take advantage of all the *other* security > features of SELinux or something similar. In other words - if you want to be > an LSM, you need to be full-featured enough to cover all the bases, not just > a few cherry-picked ones. Well, I can make Yama stack, but I suspect I shouldn't waste my time on that since Yama itself would be rejected on different grounds. I'm sure you can see how this appears to be a catch 22. "We don't need stacking because nothing needs to be stacked, and we don't need a micro-LSM because it can't be used due to lack of stacking." > protect". I won't disagree with the concept that DAC isn't usually sufficient > - the point is that ad-hoc fixes for the low-hanging fruit isn't doing anybody > any favors. This is the basis of our disagreement. Fixing it does do people a favor. At the very least, it does me a favor because now I don't have to publish security updates for an entire class of vulnerability. > The problem is that "proving it does what it claims" and "proving it > actually provides security" are two very different things. Understood. I get what you're saying about the models, and my only real defense here is that I didn't want these features in an LSM to begin with, so I don't mind it not being an LSM. That said, again, we disagree, it does actually provide security. I can point to lists of vulnerabilities where the symlink/hardlink protection actually does really block the exploit. > If somebody attacks via a different symlink attack than Yama checks for, is it > a Yama failure? If somebody attacks via a non-symlink attack, was that a Yama > failure or no? I think this is irrelevant; the symlink/hardlink combo fixes a vulnerability with DAC. It's a break in the DAC security model. > If I find a way to trick SELinux into allowing me to scribble on /etc/passwd, > that's an SELinux failure. If I find a way to do an end-run around Tomoyo, or > Smack, or AppArmor, that's a failure. And if I write to the SELinux or Tomoyo > or Smack or AppArmor folks, I'm quite certain they'll all send back a reply "Oh > damn, that shouldn't happen, we'll think about a policy or code fix to prevent > that". Right, though my objection to all MACs is that they are on top of DAC, and that large portions of the Linux user base do not use a MAC, but they cannot avoid DAC. Since the symlink/hardlink issue is with DAC, it should be fixed there, not in a MAC layer above. > But scribbling on /etc/passwd by using any of the 4,394 different known attacks > against Linux except the 1 that Yama protects against isn't considered a > problem. > > Do you see the difference? I get what you're saying. It is convincing me that the symlink/hardlink features make no sense as an LSM. > "There are two kinds of cryptography in this world: cryptography that will stop > your kid sister from reading your files, and cryptography that will stop major > governments from reading your files. This book is about the latter." > -- Bruce Schneier, "Applied Cryptography" > > The same sort of distinction applies to security. Right. But I'm trying to help protect people from their kid sister too. Unfortunately, the use-case is where it's both the kid sister admin with no MAC policy being attacked by the kid sister script kiddie with a symlink race exploit due to the kid sister programmer who wrote an application that uses a guessable /tmp file. (With apologies to kid sisters everywhere; I just wanted to continue the quoted metaphor.) > I'm sure there's several dozen other practical attacks that a motivated > attacker can come up with. So now you've traded "protect one ptrace() syscall" > for "protect against abuse of at least a dozen system calls". You're completely right that the PTRACE exception idea isn't perfect. It could be raced between the crasher's fork()/exec() and prctl(). There are probably more cases, but it sure is better than just letting everything PTRACE everything else. While waiting for smarter people than me make it impossible to exploit security vulnerabilities in the future, I want to make it harder for attackers to exploit security vulnerabilities now. > That's why you need an actual model, not ad-hoc rules. Start with "This program > has data we don't want leaked, by ptrace or any other means". Work from there. Heh, well, I have a PTRACE model. :) "Only CAP_SYSADMIN can PTRACE_ATTACH." Unfortunately, I'm stuck with these damned crash handlers which are really just hacks to avoid writing a core to disk. Oddly, this is a solved problem (via core dump patterns and distro-wide crash handlers), but some applications want to opt out of it instead of providing proper system hooks to do crash analysis. Of course, with PTRACE still allowed, there's no carrot (or stick) to encourage application writers to use distro-provided crash handlers. -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: Valdis.Kletnieks on 3 Aug 2010 22:10 On Tue, 03 Aug 2010 15:34:51 PDT, Kees Cook said: > On Tue, Aug 03, 2010 at 05:38:20PM -0400, Valdis.Kletnieks(a)vt.edu wrote: > > The fact that a patch for one case has been used for years doesn't mean > > that it's a well thought out fix for the general case. > > Well, we clearly disagree on this point. :) Actually, we do, because you yourself have stated that: a) It's a patch for one case. b) It's been around for 15 years. c) It doesn't even try to address the general case. So Yama is a special case that after years still doesn't cover the genera case :) > > - the point is that ad-hoc fixes for the low-hanging fruit isn't doing anybody > > any favors. > > This is the basis of our disagreement. Fixing it does do people a favor. At > the very least, it does me a favor because now I don't have to publish > security updates for an entire class of vulnerability. Umm.. Tell you what. I'll give you a chance to pretend you didn't send that from a vendor e-mail address... :) Do you *really* want to go on record as saying "We didn't ship a fix for Frobozz 3.2 because The Kernel Would Stop The Obvious Exploit", when it's usually quite possible that somebody can come up with a different exploit scenario? That's also going to go over *really* well with customers who end up turning off Yama because it breaks some third-party app that's doing some batshit crazy thing it shouldn't be doing in the first place. > I think this is irrelevant; the symlink/hardlink combo fixes a > vulnerability with DAC. It's a break in the DAC security model. Actually, if you trace it through, in almost every single case of an exploit abusing a symlink, at no time does the DAC model actually get violated. Every single access *is* in fact done according to the DAC in effect. The problem is that some of the accesses are not the ones the programmer intended the software to make. > Right, though my objection to all MACs is that they are on top of DAC, and > that large portions of the Linux user base do not use a MAC, but they > cannot avoid DAC. Since the symlink/hardlink issue is with DAC, it should > be fixed there, not in a MAC layer above. As pointed out above, it's *not* a DAC issue. The abused program never actually writes to anything that the DAC doesn't allow it to. In fact, a moment's thought will show that in general, a DAC *cannot* by definition actually secure a system - because the D stands for Discretionary. And most of the abuses you're trying to stop are basically convincing a program to abuse its discretionary choices. DAC is by definition "The user/program gets to decide who gets what access, and we trust the user/program to take actions that implement its decisions". (Here is where you insert the clip from Indiana Jones and the Last Crusade: "He chose... poorly"). That's DAC in a nutshell. The break is *not* in DAC, because it was never intended to defend against certain classes of threats (namely, programs that can be accidentally tricked into do things they didn't intend to, but the DAC says they can do). The break is in your idea that DAC can actually enforce security (which it can't - you need MAC for that). > Right. But I'm trying to help protect people from their kid sister too. > Unfortunately, the use-case is where it's both the kid sister admin with no > MAC policy being attacked by the kid sister script kiddie with a symlink > race exploit due to the kid sister programmer who wrote an application that > uses a guessable /tmp file. > You're completely right that the PTRACE exception idea isn't perfect. It > could be raced between the crasher's fork()/exec() and prctl(). There are > probably more cases, but it sure is better than just letting everything > PTRACE everything else. > While waiting for smarter people than me make it impossible to exploit > security vulnerabilities in the future, I want to make it harder for > attackers to exploit security vulnerabilities now. The sad part is that there are already known ways developed by smarter people. You just refuse to consider them as solutions and keep trying to deploy stuff that a sufficiently clever kid sister can bypass. > Heh, well, I have a PTRACE model. :) "Only CAP_SYSADMIN can PTRACE_ATTACH." That's not actually a full model. ;) > Unfortunately, I'm stuck with these damned crash handlers which are really > just hacks to avoid writing a core to disk. Oddly, this is a solved problem > (via core dump patterns and distro-wide crash handlers) , but some > applications want to opt out of it instead of providing proper system hooks > to do crash analysis. Of course, with PTRACE still allowed, there's no > carrot (or stick) to encourage application writers to use distro-provided > crash handlers. So do the obvious - ship with SELinux configured to not allow the arbitrary ptrace, document it, and tell them "it doesn't work, use the proper system interface instead". :)
From: Kees Cook on 3 Aug 2010 23:00 On Tue, Aug 03, 2010 at 10:07:55PM -0400, Valdis.Kletnieks(a)vt.edu wrote: > On Tue, 03 Aug 2010 15:34:51 PDT, Kees Cook said: > > On Tue, Aug 03, 2010 at 05:38:20PM -0400, Valdis.Kletnieks(a)vt.edu wrote: > > > The fact that a patch for one case has been used for years doesn't mean > > > that it's a well thought out fix for the general case. > > > > Well, we clearly disagree on this point. :) > > Actually, we do, because you yourself have stated that: > > a) It's a patch for one case. > b) It's been around for 15 years. > c) It doesn't even try to address the general case. > > So Yama is a special case that after years still doesn't cover the genera case > :) Well, Yama is just an LSM. The symlink/hardlink thing has been around forever and does sufficiently solve the general symlink race flaw. But, whatever, we disagree about this. > > This is the basis of our disagreement. Fixing it does do people a favor. At > > the very least, it does me a favor because now I don't have to publish > > security updates for an entire class of vulnerability. > > Umm.. Tell you what. I'll give you a chance to pretend you didn't > send that from a vendor e-mail address... :) > > Do you *really* want to go on record as saying "We didn't ship a fix for > Frobozz 3.2 because The Kernel Would Stop The Obvious Exploit", when it's > usually quite possible that somebody can come up with a different exploit > scenario? That's also going to go over *really* well with customers who end up > turning off Yama because it breaks some third-party app that's doing some > batshit crazy thing it shouldn't be doing in the first place. Well, it drastically reduces the urgency of such a vulnerability. Besides, if this makes a million systems safer and 1 less safe, that's still a net win. > > I think this is irrelevant; the symlink/hardlink combo fixes a > > vulnerability with DAC. It's a break in the DAC security model. > > Actually, if you trace it through, in almost every single case of an exploit > abusing a symlink, at no time does the DAC model actually get violated. Every > single access *is* in fact done according to the DAC in effect. The problem is > that some of the accesses are not the ones the programmer intended the software > to make. I'm not convinced. I see what you're trying to say, but I just don't agree. The symlink/hardlink thing is a tiny corner case of the operational conditions under which DAC operates, and this is fixing a mistake in the design that leads programmers into a (well known but seemingly unavoidable) trap. > that implement its decisions". (Here is where you insert the clip from Indiana > Jones and the Last Crusade: "He chose... poorly"). Yeah, my next trick will be helping people confine their web applications. Hahaha ugh. That's an area of endless poor choices. > > While waiting for smarter people than me make it impossible to exploit > > security vulnerabilities in the future, I want to make it harder for > > attackers to exploit security vulnerabilities now. > > The sad part is that there are already known ways developed by smarter people. > You just refuse to consider them as solutions and keep trying to deploy stuff > that a sufficiently clever kid sister can bypass. We'll agree to disagree. And at the same time I'll point out that if SELinux is off (or app is running without policy), symlink races are just as bad. > > Heh, well, I have a PTRACE model. :) "Only CAP_SYSADMIN can PTRACE_ATTACH." > > That's not actually a full model. ;) alt.ptrace.die.die.die > > Unfortunately, I'm stuck with these damned crash handlers which are really > > just hacks to avoid writing a core to disk. Oddly, this is a solved problem > > (via core dump patterns and distro-wide crash handlers) , but some > > applications want to opt out of it instead of providing proper system hooks > > to do crash analysis. Of course, with PTRACE still allowed, there's no > > carrot (or stick) to encourage application writers to use distro-provided > > crash handlers. > > So do the obvious - ship with SELinux configured to not allow the arbitrary ptrace, > document it, and tell them "it doesn't work, use the proper system interface instead". > > :) Perhaps later. For the moment, I'm happy with my racey anti-PTRACE solution. -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: Tetsuo Handa on 4 Aug 2010 00:00
Valdis.Kletnieks(a)vt.edu wrote: > That's why you need an actual model, not ad-hoc rules. Start with "This program > has data we don't want leaked, by ptrace or any other means". Work from there. /usr/sbin/sshd deals data (e.g. the content of /etc/shadow) which we don't want leaked, by ptrace or any other means. Please execute below commands on a system protected by SELinux, provided that permissions to execute below commands are given. # killall -KILL sshd # /usr/sbin/sshd -o 'Banner /etc/shadow' # ssh localhost The person who manages SELinux's policy believes that /etc/shadow is not leaked by the root user (e.g. "cat /etc/shadow" piped to "mail" command). But the root user can be different from the person who manages SELinux's policy (it can be a non-root user executing above commands using "sudo" command). > But scribbling on /etc/passwd by using any of the 4,394 different known attacks > against Linux except the 1 that Yama protects against isn't considered a > problem. Leaking the content of /etc/shadow by using "banner" option isn't considered a problem, is it? What SELinux developers think "security" is not always same as what Linux users and non SELinux developers think. An app is dealing credit card information which we don't want leaked, by ptrace or any other means. But that app needs to send mail in order to report results. Who can prove that SELinux prevents that app from leaking credit card information while keeping that app working? Nobody can. SELinux is good at dealing read/write/execute permission and is a good solution for isolating information. But SELinux is not a perfect solution for controlling how the information is used (in other words, for what purpose the information is used). I can't believe in "information flow control" or BLP model because information itself cannot be labeled. Expecting LSM modules to guarantee "Data dealt by this program is never leaked, by ptrace or any other means" sounds an illusion for me. TOMOYO is less good at dealing read/write/execute permission but is better at dealing parameters (e.g. filename, command line arguments, environment variables, DAC mode) that affect how the information is used. Although, TOMOYO does not make any guarantee like BLP model, TOMOYO is addressing problems which SELinux is not addressing. > It will likely not be accepted as an in-tree LSM, especially given that currently > it's rather difficult to stack two LSM's - which means that if a site wants to > run Yama, it becomes unable to take advantage of all the *other* security > features of SELinux or something similar. In other words - if you want to be > an LSM, you need to be full-featured enough to cover all the bases, not just > a few cherry-picked ones. If a site wants to run TOMOYO, it becomes unable to take advantage of SELinux. No LSM module is full-featured enough to cover all the bases. TOMOYO was accepted as an in-tree LSM nonetheless TOMOYO is covering only a few cherry-picked ones. I don't have a plan to make TOMOYO cover all the bases by reinventing what SELinux/Smack already does. Rather, I want to stack/chain LSM modules so that TOMOYO can be used with SELinux/Smack/AppArmor/Yama. I'm not happy to keep Yama out-of-tree because of "Yama covers only a few cherry-picked ones" and "LSM is not stackable/chainable". I believe LSM should become stackable/chainable. -- 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/ |