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 06:20 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. >> It's the same nak as before -- I concluded there was consensus on the >> lists, but was wrong. >> The opinion as well as the NAK by Christoph was discussed and supported by other developers. >>> James, will it stay in security-testing for .37 hopefully? >>> >> Not with this approach, I'd imagine. >> Yes, because it supports as an experiment the development of the LSM architecture in general. > I'm sorry to appear dense, but the most recent NAK from Christoph was > here[1], which was for a patch to Yama that is not in security-testing > yet. Prior to that, all I could find was this[2] which explicitly asked > me to put stuff in a special LSM. > That is not quite right. It is correct that this special Yama LSM was accepted so far. The inclusion into mainline was not an issue at that time. But we discussed as well that the problem of chaining of small or large LSMs is not an argument for the existence of the Yama LSM, and that the LSM architecture should be developed further so that all of the functionalities of other securtiy packages without an LSM can be integrated as a whole by a new version of the LSM system in the future and not by ripping them of like it was done with the Yama LSM [3]. You can see these objections [3] as a second NAK, but now from a company's developer (I haven't said this before, because I'm not a hard core kernel developer). > I really would like to see it in mainline, but next steps are not clear. > > -Kees > > [1] http://lkml.org/lkml/2010/6/30/31 > [2] http://lkml.org/lkml/2010/6/1/78 > > [3] http://lkml.org/lkml/2010/6/30/64 Have fun in the sun 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: Christoph Hellwig on 2 Aug 2010 08:30 On Mon, Aug 02, 2010 at 12:18:46PM +1000, James Morris wrote: > On Fri, 30 Jul 2010, James Morris wrote: > > > One issue which needs to be addressed is to confirm that there is > > consensus on the new Yama LSM module. I had thought there was, based on > > list discussion, but have since had differing feedback. > > I'm going to revert the Yama stuff for 2.6.36 -- Christoph has nacked it > to me off-list. I'm also happy to do it on-list, but I really didn't want to do it before I've actually validated the patches in your tree still are the same that were objected before. As mentioned a few times during the past discussion moving broken code into a LSM doesn't magically fix it. In fact YAMA is not any kind of (semi-)coherent security policy like Selinux, smack or similar but just a random set of hacks that you didn't get past the subsystem maintainers. Al gave you some very clear advice how a the sticky check should be done for symlinks (if we need it at all, which I tend to disagree with), 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 code past Roland and Oleg that's fine, but just pushing it out into a tree that has percieved easier merge criteria doesn't work. -- 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 2 Aug 2010 13:00 Hi Christoph, On Mon, Aug 02, 2010 at 08:24:21AM -0400, Christoph Hellwig wrote: > As mentioned a few times during the past discussion moving broken > code into a LSM doesn't magically fix it. In fact YAMA is not any kind > of (semi-)coherent security policy like Selinux, smack or similar but > just a random set of hacks that you didn't get past the subsystem > maintainers. I would love to have these "hacks" in the subsystem directly. But no one has stepped forward to decode Al Viro's hints. I'm getting pretty tired of moving this logic back and forth between the subsystems and an LSM. You yourself told me to put these things in an LSM[1], and yet now you're saying I shouldn't. > 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. > 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. > 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. > code past Roland and Oleg that's fine, but just pushing it out into > a tree that has percieved easier merge criteria doesn't work. 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 Since the latter has been repeatedly denied, the former was suggested to me, which I implemented. The option "give up" is not available to me. Perhaps there is another option I could choose from so I can get these protections into the mainline kernel? -Kees [1] http://lkml.org/lkml/2010/6/1/78 [2] http://lkml.org/lkml/2010/6/4/44 -- 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 2 Aug 2010 14:10 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.) -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: David P. Quigley on 2 Aug 2010 14:50
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. Dave -- 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/ |