Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754794AbbGQROQ (ORCPT ); Fri, 17 Jul 2015 13:14:16 -0400 Received: from smtp103.biz.mail.bf1.yahoo.com ([98.139.221.62]:37306 "EHLO smtp103.biz.mail.bf1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753478AbbGQROM (ORCPT ); Fri, 17 Jul 2015 13:14:12 -0400 X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ydcyWVsVM1kvC16GzpkbQ.LrcIShuul5YjizupHCHhwbtTI hiAmK2DXb1qtOR0WNntJPer2Il5pNacEi1OIMNd8jd5i_taDJCsjbdXYO2aY T1nZyckl2tYJNKAPJIiTqa7jfh6rWkA4eTUNJHzzT4PN2A5cg13BlgpBdvJN w7AaaGPY_IoFpz1DFZqUh0gkflsNj.lGQn2eb5Z4vf1EJRskZM53XvjVM8DG iaAaktRbjVweO_mf5nGcx71YVpNQxzbLAW5IGwthntWN9r8EOZjO0fH7zmuD XZzMyREoUo7cowmHQ2UZsfDgz90e4oBTxF8BBExIvX3IHUvqQ5K1.0TDTueX NvBSrTxa10hLuieE6HbLvP_t8ugp.ugAJwsZdUyxor5elR0jpkIOME.9Ngmr _7qPr8li1MO6gZHdxyGGH2xJz40yjB5nIJeK1MHPD1rFKz4G0DkU6gVg87hE OjGSQiUJhnroSnq1XUq7OLraIJJuHsVw13b1OhO4_CEp.egEretq9T7tCFVI qEz4X0zvz85RjDihcVl1I2ehZKbWlsq06Sw-- X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Subject: Re: [PATCH 0/7] Initial support for user namespace owned mounts To: Seth Forshee References: <1436989569-69582-1-git-send-email-seth.forshee@canonical.com> <87615k7pyu.fsf@x220.int.ebiederm.org> <20150716135947.GC77715@ubuntu-hedt> <55A7C920.7090206@schaufler-ca.com> <20150716185750.GB51751@ubuntu-hedt> <55A8253E.3000407@schaufler-ca.com> <20150717132146.GA65566@ubuntu-hedt> Cc: "Eric W. Biederman" , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov, Serge Hallyn , Andy Lutomirski , linux-kernel@vger.kernel.org From: Casey Schaufler Message-ID: <55A937E1.8040605@schaufler-ca.com> Date: Fri, 17 Jul 2015 10:14:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150717132146.GA65566@ubuntu-hedt> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4422 Lines: 89 On 7/17/2015 6:21 AM, Seth Forshee wrote: > On Thu, Jul 16, 2015 at 02:42:22PM -0700, Casey Schaufler wrote: > > > >>> I welcome feedback about anything I've missed, but stating generally >>> that you think I probably missed something isn't very helpful. >> True enough. I hope I've explained myself above. > Thanks, that definitely clarified where we were having a disconnect. > Andy's done a fantastic job explaining how those concerns are addressed. > >>> The LSM issue is thornier than the rest of it though, which is why I >>> specifically asked for review there in the cover letter. There's a lot >>> of complexity and nuance, and I still don't have a grasp on all the >>> subtleties. One such subtlety is the full impact of simply ignoring the >>> security labels on disk (but I am still confused as to why this is >>> different from filesystems which don't support xattrs at all). >> If you can mount a filesystem such that the labels are ignored you >> are effectively specifying that the Smack label on the files be >> determined by the defaulting rules. With CAP_MAC_ADMIN that's fine. >> Without it, it's not. >> >>> I was unaware of Lukasz's patches until yesterday, and I will have a >>> look at them. But since we don't have the LSM support for user >>> namespaces yet, I don't see the problem with doing something safe for >>> LSMs initially and evolving the LSM integration for user ns mounts along >>> with the rest of the user ns integration. >> Ignoring the security attributes is not safe! > Understood. It's surely safe for each LSM to deny such mounts until it > has a way to handle them safely though. > > I'm not trying to completely punt on the issue of security modules, just > break this down into more manageable chunks. You've given good guidance > for Smack (thanks very much for that), so I can plan to work on that > soon. > >>> Your point is taken about my less-than-expert opinion about the other >>> security modules. We should at minimum get acks from the maintainers of >>> those modules that unprivileged mounts will not compromise MAC. >> I am the Smack maintainer. Unprivileged mounts as you have >> described them compromise MAC. They compromise DAC, too. > It looks like Andy's more or less convinced you that DAC isn't > (additionally?) compromised. And there's a plan for MAC, that the > security module can deny mounts from user namespaces until it has a > solution for allowing them safely. I wouldn't say that Andy has me convinced on DAC. I would say that he's taken me deeper into the details of namespaces than I feel comfortable making arguments about. I don't know that he's right, I just don't know how to argue that he isn't. Part of what bothers me is the dependence on namespaces. If you could come up with a mechanism that wasn't dependent on namespaces it would be much easier for dinosaurs like me to comprehend. As far as declaring that MAC and namespace owned mounts are incompatible goes, I think that I said early on that wasn't going to fly. Too much of the Linux population (Fedora, Android, Tizen, ...) uses MAC for the feature to be considered ready for general consumption without it. And no, I don't believe in partial implementations. You wouldn't get away with putting this in if it only worked on s370 processors. >>> For Smack specifically, I believe my only concern was the SMACK64EXEC >>> attribute, as all the other attributes only affected subjects' access to >>> the files. So maybe it would be possible to simply ignore this attribute >>> in unprivileged mounts and respect the others, even lacking more >>> complete LSM support for user namespaces. >> SMACK64EXEC is analogous to the setuid bit, but I would rather see >> exec() of programs with this attribute refused that for it to be >> blindly ignored. > That's fine, it's your call. I said it, but on reflection the current NOSETUID behavior is as you described it, so I wouldn't change that. > > Thanks, > Seth > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/