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=-3.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 29C94C38A2B for ; Fri, 17 Apr 2020 16:59:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 039AB2054F for ; Fri, 17 Apr 2020 16:59:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=paul-moore-com.20150623.gappssmtp.com header.i=@paul-moore-com.20150623.gappssmtp.com header.b="YE8SLodB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728012AbgDQQ7Y (ORCPT ); Fri, 17 Apr 2020 12:59:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58660 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726724AbgDQQ7Y (ORCPT ); Fri, 17 Apr 2020 12:59:24 -0400 Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07BCFC061A0F for ; Fri, 17 Apr 2020 09:59:22 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id i7so1999666edq.3 for ; Fri, 17 Apr 2020 09:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=04NkHXi+PwY9BSJltFl8mSuXJp2mIc+S/1/r3t62y+w=; b=YE8SLodByGOd+rm5xUZh0C0gSqL0bxPRbfdU0WS9RxReb3iIqQCYxJ/4w/js897/6u f1widm+GipXqhNOkCvt0l5JteWm1PkpilV7jI+Qos/4qQdHZGxt1kZyVlz4+rxpmD0oW +1cJ6oto0syR2PVYZBIB/Nk9LWyzHzR4bXVUmG9gOx4D5cNinoE0ogrPjywQI7PTvWdE G1o1M/j064YBQmNiUK9X+IXnX4aqEvYMvVumsBBLcG2EWjROf1WTCwUP+i/G4SsJ5jyf 8C368PktpEZsWU5vsaIPMxanFpjVIxs4C9mlgBhRm8sQGHtgmvRd3pRHbuvck7wEnHsL 5rFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=04NkHXi+PwY9BSJltFl8mSuXJp2mIc+S/1/r3t62y+w=; b=GQhklcZKeEyeXr+wZzSbv5Ub8qHH0o/4/QHVqg1OJEEtHLSoW1PmgVRBU2oD9WYSFe dLOwvdxL4uezqVha6IQXV5bgPT4mJfMdv1mwaxLHBWsth8WoT/c5ts2MdkQY45J0gwOB hRYkBfl14DX0AfQ8vtK3DgC42iVJivs0pCr5cTwL/wcxL2Le5Lcwd1OLI6VtvT5BaCR/ rECq+i69q9FhY02CyCPYLLwah8BRCj5cPMlK9d8WXWCLTWzUNyPR1rQRDsQGAhCu4C0h wG+A3pkASghyB5k2XHvL7s2xrCqhqvDYqzB/3zXopPP7nQSyRl7ucqT8UPAYTWqJKXC1 j+hg== X-Gm-Message-State: AGi0PuZJGYgW52xrPm5tVEW7Slkwk1miYL16O3s2TXBimav1ywql38lx vu4Inh1DMu4L6fABBn5TxafMcah1/PuEi6n6YpGd X-Google-Smtp-Source: APiQypIXLCfwICgpSyK/g0V1Gk4QDbVPh3cx9SkB08ZjMy0TQcd6CsugDzeQCPWhvb9tbm52Esiq2ol7z+/fB88qqVA= X-Received: by 2002:aa7:c352:: with SMTP id j18mr3759570edr.196.1587142761495; Fri, 17 Apr 2020 09:59:21 -0700 (PDT) MIME-Version: 1.0 References: <56808ee47c8b6e184fd013b90072c6fb07ef84f2.camel@btinternet.com> In-Reply-To: <56808ee47c8b6e184fd013b90072c6fb07ef84f2.camel@btinternet.com> From: Paul Moore Date: Fri, 17 Apr 2020 12:59:10 -0400 Message-ID: Subject: Re: Problem with 9ba09998baa9 ("selinux: Implement the watch_key security hook") in linux-next To: Richard Haines Cc: David Howells , keyrings@vger.kernel.org, selinux@vger.kernel.org, linux-security-module@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Fri, Apr 17, 2020 at 12:32 PM Richard Haines wrote: > On Fri, 2020-04-17 at 11:48 -0400, Paul Moore wrote: > > I just notice that the "selinux: Implement the watch_key security > > hook" patch made it's way into linux-next via 9ba09998baa9: > > > > commit 9ba09998baa995518d94c9a32e6329b28ccb9045 > > Author: David Howells > > Date: Tue Jan 14 17:07:13 2020 +0000 > > > > selinux: Implement the watch_key security hook > > > > Implement the watch_key security hook to make sure that a key > > grants the > > caller View permission in order to set a watch on a key. > > > > For the moment, the watch_devices security hook is left > > unimplemented as > > it's not obvious what the object should be since the queue is > > global and > > didn't previously exist. > > > > Signed-off-by: David Howells > > Acked-by: Stephen Smalley > > > > I'm reasonably confident that this code hasn't been tested as I > > expect > > it would fail, or at the very least behave in unintended ways. The > > problem is the selinux_watch_key(...) function, shown below: > > I built an selinx-testsuite test for this last year and it worked fine > then. I'll send the test as an RFC patch as its been some time since I > ran it. David also has a test in kernel > samples/watch_queue/watch_test.c See below. > > +static int selinux_watch_key(struct key *key) > > +{ > > + struct key_security_struct *ksec = key->security; > > + u32 sid = current_sid(); > > + > > + return avc_has_perm(&selinux_state, > > + sid, ksec->sid, SECCLASS_KEY, > > KEY_NEED_VIEW, NULL); > > +} > > > > ... in particular it is the fifth argument to avc_has_perm(), > > "KEY_NEED_VIEW" which is a problem. KEY_NEED_VIEW is not a SELinux > > True, however by magic the KEY_NEED_* perms match with the bits defined > in classmap.h. I did some work on this during the 'keys' saga, see > various emails in list like [1] > > [1] > https://lore.kernel.org/selinux/20200220181031.156674-2-richard_c_haines@btinternet.com/ Esh, relying on the constants to line up is a recipe for disaster. We really need that permission translation layer. -- paul moore www.paul-moore.com