Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752642AbbEZOhG (ORCPT ); Tue, 26 May 2015 10:37:06 -0400 Received: from emvm-gh1-uea09.nsa.gov ([63.239.67.10]:65394 "EHLO emvm-gh1-uea09.nsa.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752595AbbEZOg7 (ORCPT ); Tue, 26 May 2015 10:36:59 -0400 X-TM-IMSS-Message-ID: <32a1a4630005d9f6@nsa.gov> Message-ID: <556484BD.2060004@tycho.nsa.gov> Date: Tue, 26 May 2015 10:35:41 -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 , "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 CC: 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> In-Reply-To: <1432557162-19123-1-git-send-email-l.pawelczyk@samsung.com> 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: 3016 Lines: 58 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. > --- Usage --- > > Smack namespace is written using LSM hooks inside user namespace. That > means it's connected to it. > > To create a new Smack namespace you need to unshare() user namespace > as usual. If that is all you do though, than there is no difference to > what is now. To activate the Smack namespace you need to fill the > labels' map. It is in a file /proc/$PID/smack_map. This should be /proc/$PID/attr/label_map or similar, modeled after the existing /proc/$PID/attr/current and similar nodes. Then it isn't module-specific and can be reused for other modules. > Writing to the map file is not disabled after the first write as it is > in uid_map. For Smack we have no means to map ranges of labels, hence > it can really be advantageous to be able to expand the map later > on. But you can only add to the map. You cannot remove already mapped > labels. You cannot change the already existing mappings. Also mappings > has to be 1-1. All requests to create a map where either the unmapped > or the mapped label already exists in the map will be denied. Isn't it a concern that I can then add additional labels to the mapping for which I am not authorized? Or is this mitigated by the fact that I cannot alter the rules? What about the situation for the predefined labels in Smack - are you assuming that they will always be mapped up front in the mapping file? -- 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/