linux-kernel - Re: [PATCH v2 0/7] Smack namespace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 May 2015 12:34:16 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Lukasz Pawelczyk <l.pawelczyk@...sung.com>
CC:	"David S. Miller" <davem@...emloft.net>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Casey Schaufler <casey@...aufler-ca.com>,
	David Howells <dhowells@...hat.com>,
	Fabian Frederick <fabf@...net.be>,
	Greg KH <gregkh@...uxfoundation.org>,
	James Morris <james.l.morris@...cle.com>,
	Jeff Layton <jlayton@...marydata.com>,
	Jingoo Han <jg1.han@...sung.com>,
	Joe Perches <joe@...ches.com>,
	John Johansen <john.johansen@...onical.com>,
	Jonathan Corbet <corbet@....net>,
	Kees Cook <keescook@...omium.org>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Miklos Szeredi <miklos@...redi.hu>,
	Oleg Nesterov <oleg@...hat.com>,
	Paul Moore <paul@...l-moore.com>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	Zefan Li <lizefan@...wei.com>,
	Rafal Krypa <r.krypa@...sung.com>, linux-doc@...r.kernel.org,
	linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	containers@...ts.linux-foundation.org,
	Lukasz Pawelczyk <havner@...il.com>
Subject: Re: [PATCH v2 0/7] Smack namespace

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/