Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932197AbbEZQfZ (ORCPT ); Tue, 26 May 2015 12:35:25 -0400 Received: from emvm-gh1-uea09.nsa.gov ([63.239.67.10]:59793 "EHLO emvm-gh1-uea09.nsa.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751143AbbEZQfV (ORCPT ); Tue, 26 May 2015 12:35:21 -0400 X-TM-IMSS-Message-ID: <330e25e30006050c@nsa.gov> Message-ID: <5564A088.4040507@tycho.nsa.gov> Date: Tue, 26 May 2015 12:34:16 -0400 From: Stephen Smalley Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Lukasz Pawelczyk CC: "David S. Miller" , "Eric W. Biederman" , "Kirill A. Shutemov" , "Serge E. Hallyn" , Al Viro , Alexey Dobriyan , Andrew Morton , Andy Lutomirski , Casey Schaufler , David Howells , Fabian Frederick , Greg KH , James Morris , Jeff Layton , Jingoo Han , Joe Perches , John Johansen , Jonathan Corbet , Kees Cook , Mauro Carvalho Chehab , Miklos Szeredi , Oleg Nesterov , Paul Moore , Tetsuo Handa , Zefan Li , Rafal Krypa , linux-doc@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, containers@lists.linux-foundation.org, Lukasz Pawelczyk Subject: Re: [PATCH v2 0/7] Smack namespace References: <1432209222-8479-1-git-send-email-l.pawelczyk@samsung.com> <1432557162-19123-1-git-send-email-l.pawelczyk@samsung.com> <556484BD.2060004@tycho.nsa.gov> <1432657655.1974.21.camel@samsung.com> In-Reply-To: <1432657655.1974.21.camel@samsung.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3129 Lines: 63 On 05/26/2015 12:27 PM, Lukasz Pawelczyk wrote: > Hi, > > Thanks for taking the interest and commenting on this. > Replies below. > > > On wto, 2015-05-26 at 10:35 -0400, Stephen Smalley wrote: >> On 05/25/2015 08:32 AM, Lukasz Pawelczyk wrote: >>> --- Design ideas --- >>> >>> "Smack namespace" is rather "Smack labels namespace" as not the whole >>> MAC is namespaced, only the labels. There is a great analogy between >>> Smack labels namespace and the user namespace part that remaps UIDs. >>> >>> The idea is to create a map of labels for a namespace so the namespace >>> is only allowed to use those labels. Smack rules are always the same >>> as in the init namespace (limited only by what labels are mapped) and >>> cannot be manipulated from the child namespace. The map is actually >>> only for labels' names. The underlying structures for labels remain >>> the same. The filesystem also stores the "unmapped" labels from the >>> init namespace. >> >> How do you achieve that without introducing additional hooks or >> reworking the current hooks in the setxattr code path? At present, the >> security module is allowed to rewrite getxattr requests on the >> security.* namespace but it isn't allowed to do that for setxattr, so if >> the process invokes setxattr with a mapped label, then it will be the >> mapped label that gets passed to the filesystem implementation, not the >> unmapped label. The security module may internally store it in unmapped >> form and may even return that upon getxattr() calls, but if you then >> reboot the system and later fetch from the filesystem, it will get the >> mapped label value. > > I call the inode operation by hand in the post_setxattr. > > The label will effectively be set twice, which is not ideal, but there > is no other option right now without reworking the hooks as you said. > > This shouldn't really be a problem because the Smack operations will not > use the filesystem label (even when it's set incorrectly for a moment) > but an already initialized smack_known structure for this inode that has > all the values filled in properly. > > The only attack vector I can think of is hard rebooting the machine in a > way that mapped label is really saved in the filesystem before the > unmapped will have a chance. Should I be worried about that? This sounds > a little unreal. If it were my security module, I would be worried about it. Even aside from maliciously induced failure, you are leaving yourself open to inconsistencies arising upon crashes. I would suggest modifying the setxattr hook so that the security module can override the original value/size pair with its own definition before it is passed to the inode operation. There is already precedent in that security modules are allowed to override the value/size returned by getxattr for security.*, so this just makes them fully parallel. -- 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/