From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 482CDC433DF for ; Thu, 23 Jul 2020 13:37:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 253A5207BB for ; Thu, 23 Jul 2020 13:37:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=defensec.nl header.i=@defensec.nl header.b="gl+x3HBI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727859AbgGWNhm (ORCPT ); Thu, 23 Jul 2020 09:37:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727123AbgGWNhm (ORCPT ); Thu, 23 Jul 2020 09:37:42 -0400 Received: from agnus.defensec.nl (agnus.defensec.nl [IPv6:2001:985:d55d::711]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4EB8DC0619DC for ; Thu, 23 Jul 2020 06:37:42 -0700 (PDT) Received: from [IPv6:2001:985:d55d::438] (brutus [IPv6:2001:985:d55d::438]) by agnus.defensec.nl (Postfix) with ESMTPSA id C07652A1007; Thu, 23 Jul 2020 15:37:38 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 agnus.defensec.nl C07652A1007 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=defensec.nl; s=default; t=1595511459; bh=3RDphjLkzUcm6v6BXLUb6iCsm9BQZI8Dmqp6aOZyXas=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gl+x3HBI1lIRFzAM9qbQYb1sOYFHnnIVRBYglYpVmktuEWr76EhphvwhpsvwkPpvp HmSGiKrnhd6rjqCtSGSyZYY6R2Yt7bz2jodKmkDV1jd8tCIQrYWdNwzVt84g+OnqBC DwPC6x+3A/LIC9/MfMWu36TFT8NotPS5T8XImb+Q= Subject: Re: [SELinux-notebook PATCH v8] objects.md: some clarifications To: Stephen Smalley Cc: SElinux list References: <20200721195153.1974509-1-dominick.grift@defensec.nl> <20200721200230.1976501-1-dominick.grift@defensec.nl> <39629738-f5db-e784-1f57-e6b8958b73ac@defensec.nl> From: Dominick Grift Autocrypt: addr=dominick.grift@defensec.nl; keydata= mDMEXpatqRYJKwYBBAHaRw8BAQdAJfdyO5XDdJ1R0DhG9EIDgaPAH3IcDxwCMAMX+BNXEi20 K0RvbWluaWNrIEdyaWZ0IDxkb21pbmljay5ncmlmdEBkZWZlbnNlYy5ubD6IlgQTFggAPhYh BPFdMErUJbkJPwIOqdoAaTu+GpgJBQJelq2pAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQWAgMB Ah4BAheAAAoJENoAaTu+GpgJN5cBAPpUgfvLek9pJ1o3zIxN0GBNs1OxIAqxeCvNxrdts3WN AP0T2QRpO9ti7JMWXkd3AXR7uCiYeU25PuepfRyjsUAYDLg4BF6WrakSCisGAQQBl1UBBQEB B0DRoS9PVlLY/xm36SxVLVbVLIKtdmTzM95muFiqEtI0LQMBCAeIfgQYFggAJhYhBPFdMErU JbkJPwIOqdoAaTu+GpgJBQJelq2pAhsMBQkJZgGAAAoJENoAaTu+GpgJhmYA/0NnwIlVEgyd 6NRnjqrpkSZTiGVGIItP3ukxXYQ424drAP9LVU1SyOTNIL+S6OYYEIMosEFDjffjz6jXmsv7 WXFbDA== Message-ID: <9756ba20-15b7-caad-949c-c7149526c94b@defensec.nl> Date: Thu, 23 Jul 2020 15:37:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org On 7/23/20 3:24 PM, Stephen Smalley wrote: > On Thu, Jul 23, 2020 at 9:04 AM Dominick Grift+ > wrote: >> >> >> >> On 7/23/20 2:22 PM, Stephen Smalley wrote: >>> On Thu, Jul 23, 2020 at 4:13 AM Dominick Grift >>> wrote: >>>> >>>> >>>> >>>> On 7/22/20 7:32 PM, Stephen Smalley wrote: >>>>> On Wed, Jul 22, 2020 at 12:57 PM Dominick Grift >>>>> wrote: >>>>>> Can we not just assume that if that happens, that the kernel should just >>>>>> treat the context as if it were the context of the unlabeled isid. >>>>> >>>>> No, because then a simple typo or other error in a context provided by >>>>> a user or application would end up being handled as the unlabeled >>>>> context instead of producing an error return that can be handled by >>>>> the application or user. >>>> >>>> So are you saying that it is up to the libselinux consumers to deal with >>>> this? what do you suggest they do in these situations? >>> >>> libselinux cannot handle it in the general case. If using the >>> userspace AVC and SIDs obtained via avc_context_to_sid(), then >>> libselinux could transparently re-map those to the unlabeled context >>> if they cease to be valid. Otherwise, it is up to the callers to deal >>> with and the correct handling is application-specific. SEPostgreSQL >>> does this for example: >>> https://github.com/postgres/postgres/blob/master/contrib/sepgsql/label.c#L460 >>> >>> However, I don't think that would help something like systemd; even if >>> you re-map the context to the unlabeled context, you aren't going to >>> get a useful result from security_compute_create() or similar to use >>> in labeling sockets, processes, files, etc.> >> >> I suppose systemd probably should not fail "hard" when getfilecon (or >> whatever) fails and returns with "invalid argument", and it should then >> just not use setfilecon rather than not create the object at all (as it >> seems to be doing now) > > There is a tension there with fail-closed versus fail-open and the > potential for a security vulnerability to arise if it proceeds. Would > have to look at the specifics to evaluate how it should be handled. > Of course, in practice, one really shouldn't be removing contexts > while they are still in use (or else use aliases to preserve some > degree of compatibility). > Using aliases is not a practical solution IMHO (although I suppose it could be useful temporary hack), and effectively "removing contexts while they are still in use" will alway's be the case in the current state (even autorelabel will effectively generally run when the filesystem has invalid labels, because that is the whole purpose of the app) Maybe we should should rethink that whole autorelabel concept. Do we really have to re-initialize filesystems in order to enable labeling support? Should I be able to load a different policy at runtime, then add a fsuse xattr rule, and be able to relabel at runtime without a reboot, or without somehow re-initializing the filesystem?