Upstream first policy
in [Kernel]
|
Prev: fork problem in multithreaded process -- segmentation fault seen
Next: [PATCH 2/2 V3] io-controller: Document for blkio.weight_device
From: Linus Torvalds on 4 Mar 2010 20:30 On Thu, 4 Mar 2010, Kyle McMartin wrote: > > I recommend you don't look at Ubuntu, we might have a lot of extra > crud[2] in the kernel if you do. :) (Actually, shockingly less than I > thought, just apparmor, aufs, ndiswrapper are the obvious ones.) Ok, so ndiswrapper falls under the "yeah, no" heading. But apparmor was supposed to be on the "yeah, we'll merge it" path, I talked to somebody about it not _that_ long ago. Some of the security people object, but they object for all the wrong reasons and I really do think that since it's getting used, we really should merge it. Although there was _some_ noise about Ubuntu trying to move away from it.. But that may have been more of the whole FUD thing from the people who for some unfathomable reason think that inodes are more important than pathnames. aufs I'll leave at Al's mercy. Linus -- 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 7 Mar 2010 16:30 On Thu, 4 Mar 2010, Linus Torvalds wrote: > On Thu, 4 Mar 2010, Kyle McMartin wrote: >> >> I recommend you don't look at Ubuntu, we might have a lot of extra >> crud[2] in the kernel if you do. :) (Actually, shockingly less than I >> thought, just apparmor, aufs, ndiswrapper are the obvious ones.) > > Ok, so ndiswrapper falls under the "yeah, no" heading. > > But apparmor was supposed to be on the "yeah, we'll merge it" path, I > talked to somebody about it not _that_ long ago. Some of the security > people object, but they object for all the wrong reasons and I really do > think that since it's getting used, we really should merge it. The AppArmor developer has been posting patches for review -- there's nothing stopping the code being merged except for the need to address purely technical issues raised by reviewers, which is ongoing. See: http://thread.gmane.org/gmane.linux.kernel.lsm/10443 > Although there was _some_ noise about Ubuntu trying to move away from > it.. But that may have been more of the whole FUD thing from the people > who for some unfathomable reason think that inodes are more important > than pathnames. Hey, thanks for another random unfounded personal attack, it's really appreciated. - 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: Linus Torvalds on 7 Mar 2010 16:40 On Sun, 7 Mar 2010, Linus Torvalds wrote: > > My point was just that there's a lot of mindless "my way or the > highway" in some security circles, and apparmor really has been > ridiculed. ... and perhaps more fundamentally, the deeper point was that that in no way stops the "upstream first" policy. Some Ubuntu people who wanted to get it merged were in fact worried that it might. Linus -- 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: Linus Torvalds on 7 Mar 2010 16:40 On Mon, 8 Mar 2010, James Morris wrote: > > > it.. But that may have been more of the whole FUD thing from the people > > who for some unfathomable reason think that inodes are more important > > than pathnames. > > Hey, thanks for another random unfounded personal attack, it's really > appreciated. It really isn't personal, you know. I don't even remember _who_ it was that thought that pathname-based security was fundamentally wrong and was bad-mouthing apparmor all they could. My point was just that there's a lot of mindless "my way or the highway" in some security circles, and apparmor really has been ridiculed. It's not _that_ long ago that some group was trying to get rid of LSM just because "selinux is the only valid model". Linus -- 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: Ingo Molnar on 8 Mar 2010 04:50
* James Morris <jmorris(a)namei.org> wrote: > On Thu, 4 Mar 2010, Linus Torvalds wrote: > > > On Thu, 4 Mar 2010, Kyle McMartin wrote: > >> > >> I recommend you don't look at Ubuntu, we might have a lot of extra > >> crud[2] in the kernel if you do. :) (Actually, shockingly less than I > >> thought, just apparmor, aufs, ndiswrapper are the obvious ones.) > > > > Ok, so ndiswrapper falls under the "yeah, no" heading. > > > > But apparmor was supposed to be on the "yeah, we'll merge it" path, I > > talked to somebody about it not _that_ long ago. Some of the security > > people object, but they object for all the wrong reasons and I really do > > think that since it's getting used, we really should merge it. > > The AppArmor developer has been posting patches for review -- there's > nothing stopping the code being merged except for the need to address > purely technical issues raised by reviewers, which is ongoing. > > See: http://thread.gmane.org/gmane.linux.kernel.lsm/10443 > > > Although there was _some_ noise about Ubuntu trying to move away from it.. > > But that may have been more of the whole FUD thing from the people who for > > some unfathomable reason think that inodes are more important than > > pathnames. > > Hey, thanks for another random unfounded personal attack, it's really > appreciated. Btw., now that we are a few reasonable months after the last big security flamewar it would be nice to see a rehash or fair summary of the pathname versus labels arguments. That particular issue does seem to be largely technical and thus we ought to be able to judge it one way or another. IMO the main challenge in Linux security is to find and engage the right critical mass of developers to truly increase the security of 'Linux' as a whole in the long run. That means, almost by definition, that we do not start by trying to create an 'as secure as possible' system in the short run. Increased security is the _end goal_, not the means. I.e. we need a technology _process_ that results in more secure Linux systems. ( Trying to create an 'as secure as possible' system will almost certainly backfire, as it results in _fewer_ developers/users caring. ) In that sense it appears to me that it's pretty much a universal truth that 'pathnames' are a far more fitting abstraction to any 'human based security process' on Linux than 'labels'. (It does not matter at all that security research suggest that the most secure systems are label based and that there are some hard problems with pathname based approaches such as hardlinks, --bind mounts, etc.) So here i see somewhat of a conceptual failure of SELinux that would be nice to see fixed: inherent hostility against pathname based approaches, just because they are technically less secure. To me the relabeling performance problem and the fact that selinux labels are physically attached to the objects themselves is a potentially bigger 'security problem' than the racy nature (and aliasing/ambiguity problems) of VFS pathname based security is. In other words: i see selinux's main failure in that it somewhat blindly aims for a security model that it sees as the technicaly most secure, while not being intellectually open to the fact that we very likely _cannot know in advance_ which of the models will make Linux more secure in the long run. For example did you consider the possibility that the road towards a label based approach may as well be most practical _over_ a proxy step that used pathname based security? (i.e. once there's a critical mass of pathname based security policies, and there's distros/developers/users who maintain it, a much smaller step towards labels could be attempted - possibly automated to a certain degree.) We cannot know how it will end up looking like in a few years because security is one of the few areas where computer technology mixes so strongly with psychology, and a secure system of this human scale was never attempted before. Prior security research is thus largely irrelevant. This also means that paradoxically, this intellectual inflexibility over the basic security model may as well make Linux less secure. Also, why was/(is?) AppArmor considered as a 'hostile competitor' - instead of treating it more like a natural ally: another mechanism that allows us to _expand_ the total pool of per app security policies (and, more importantly, the pool of developers who care about those policies)? Thanks, Ingo -- 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/ |