Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp2067306pxu; Fri, 9 Oct 2020 07:11:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzXrnKVLf7nzIxFwUbT9mIGljSPgfImq6s+TYTFHm5eB8YOkgO20dL7o9t5K4Sm7WTtdl3K X-Received: by 2002:a1c:cc0a:: with SMTP id h10mr13591996wmb.80.1602252709060; Fri, 09 Oct 2020 07:11:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602252709; cv=none; d=google.com; s=arc-20160816; b=r1LDZsW/T5oZhaFdsECO5LVFF7crmHvgRYQT/rY0aGTtUkF4iI8XJGeE4/Jr+7sWM/ MTw8ccay7O4ZJvP6kF7JfcrMdh98HNB5CQewdTltSoZnfjy/O8QK2C4kgBlLG0c/AblE qDAVbGxavZ9pugw81hB1gFn/9xunHZFvnfw9bTf7fhLw0W/tRrK0rttPGjbduX/cnijI FFLSm1Ko/CkUVAbVggZgs1VQUeI/9cFypS/jeAv48LJ3bz3rzuB0y73JyNuKTH2us2hb wLOcGErq7N9EF/btnMNSKFN/Bm2Qps7meGwqAEFedS1oh/JGTe4Dm7DDeSFKSIQ1nKvQ i6Tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=kBW+4/PqHA8W886GKDVa8HW7sWoRETpTXRD9CWylw7w=; b=ipt5xdwl3ub2gSgPXvpnzZ3+WJX4jBW4f9MCAHYztDhwcE3wlSiRTdsojlZvg2h1Zk 9o+fBo2F4d5pd3Cv3cTPRGjIcOX3FG5XOqKzj1M9J6PEQxSxu/JAb7vLEfuQdjnnQZJu e5guGaxPJtInk5sgmHRvByTH6YiLt4lu+l5daAsMVA8QnHRX+dZuStYO4fAjAxgheEhd S+zLGV5ua0PoYUtYb+3Vc4YbQzxc2fchxDOSj8nWivlm1Zn08awdY07M0gSCqK0Hk/gK hWwNe1X3peJVkTkq0HBmYVBLwkuyydorxkEH7k8rZRnYYYBZRkpBJ2uo9lOHuaQFpRPB q6GA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XEh+GF3V; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j1si5982845edr.167.2020.10.09.07.11.14; Fri, 09 Oct 2020 07:11:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XEh+GF3V; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732366AbgJIOIB (ORCPT + 99 others); Fri, 9 Oct 2020 10:08:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726471AbgJIOIB (ORCPT ); Fri, 9 Oct 2020 10:08:01 -0400 Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9E14C0613D2; Fri, 9 Oct 2020 07:08:00 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id d1so7991893qtr.6; Fri, 09 Oct 2020 07:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kBW+4/PqHA8W886GKDVa8HW7sWoRETpTXRD9CWylw7w=; b=XEh+GF3VLggR+3Z70dprxCVK427MftxDZlG4W1ns+/FPhaZOUcuZg6fcgPh+ELVR76 5pOF1al6o3/YuOUX2rEgnD3TuBQNGGE1QMxJ+iL8u0AxN5Dq8MvZIPUneJp0JgdVx4me ylxXm0TCMPxMu3+OgbJH9hxURTEPVX9r/BYkk4leciuzSmGYbEL2FtnMJZLt8kpeky7E IRURr4a8J9Vd9+ZewYyZlWC9Wdk2Rzw5KFt3ir/xXP+pOmJrY5p1/vbVim8t6h8lw0kL yjE7jVavc+uzUuBMb9i9CCco6x0DBbC+O4qN5v81jTZ/ytvVLpl7mLcBMQmV85vBAdZW EJsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kBW+4/PqHA8W886GKDVa8HW7sWoRETpTXRD9CWylw7w=; b=YqHbVmKIrnWODqnTzH80Fk3TFjRVRaCZH7GiigqjvrCTMBESK9rD2KVo6FmrohIXnT FTofLu/rX/zcaRTljRDuGDwqupC4bca166P7h1vXdJJX3iongNxdddHYbZJ+fajlupAB 87/euKOfkX0Ezvtez9UZNxahdbkpfgw7GId82CDFpaLxLtSEtw21MvD6zuWugG+JbQwt /GXxPy2WbYr/t0l+61MtssT9PWtaMLibmpvy+UERH6CgzkBeMPxU/tmdpkxyvyP6iisy K+NIKJQxhOYzsaPItnezSf175lTxiT1taQG8DgXilC3M3Aof9JBB8ZKqsvsZld3JZkxj p26g== X-Gm-Message-State: AOAM5303Q9jSMQX0pW3JPgdXJMUrNCr6WTdFEWYv/70AuU8q+iHoXc7W TxApHSF+lageK+CYLbo/TVk= X-Received: by 2002:ac8:d8d:: with SMTP id s13mr12976833qti.42.1602252480141; Fri, 09 Oct 2020 07:08:00 -0700 (PDT) Received: from anon-dhcp-152.1015granger.net (c-68-61-232-219.hsd1.mi.comcast.net. [68.61.232.219]) by smtp.gmail.com with ESMTPSA id x22sm3240540qki.104.2020.10.09.07.07.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 07:07:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: selinux: how to query if selinux is enabled From: Chuck Lever In-Reply-To: Date: Fri, 9 Oct 2020 10:07:58 -0400 Cc: Paul Moore , Linux Security Module list , SElinux list , Linux NFS Mailing List Content-Transfer-Encoding: 7bit Message-Id: References: To: Olga Kornievskaia X-Mailer: Apple Mail (2.3608.120.23.2.4) Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org > On Oct 9, 2020, at 7:49 AM, Olga Kornievskaia wrote: > > On Thu, Oct 8, 2020 at 9:03 PM Paul Moore wrote: >> >> ->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia wrote: >>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore wrote: >>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia wrote: >>>>> Hi folks, >>>>> >>>>> From some linux kernel module, is it possible to query and find out >>>>> whether or not selinux is currently enabled or not? >>>>> >>>>> Thank you. >>>> >>>> [NOTE: CC'ing the SELinux list as it's probably a bit more relevant >>>> that the LSM list] >>>> >>>> In general most parts of the kernel shouldn't need to worry about what >>>> LSMs are active and/or enabled; the simply interact with the LSM(s) >>>> via the interfaces defined in include/linux/security.h (there are some >>>> helpful comments in include/linux/lsm_hooks.h). Can you elaborate a >>>> bit more on what you are trying to accomplish? >>> >>> Hi Paul, >>> >>> Thank you for the response. What I'm trying to accomplish is the >>> following. Within a file system (NFS), typically any queries for >>> security labels are triggered by the SElinux (or I guess an LSM in >>> general) (thru the xattr_handler hooks). However, when the VFS is >>> calling to get directory entries NFS will always get the labels >>> (baring server not supporting it). However this is useless and affects >>> performance (ie., this makes servers do extra work and adds to the >>> network traffic) when selinux is disabled. It would be useful if NFS >>> can check if there is anything that requires those labels, if SElinux >>> is enabled or disabled. >> >> [Adding Chuck Lever to the CC line as I believe he has the most recent >> LSM experience from the NFS side - sorry Chuck :)] >> >> I'll need to ask your patience on this as I am far from a NFS expert. >> >> Looking through the NFS readdir/getdents code this evening, I was >> wondering if the solution in the readdir case is to simply tell the >> server you are not interested in the security label by masking out >> FATTR4_WORD2_SECURITY_LABEL in the nfs4_readdir_arg->bitmask in >> _nfs4_proc_readdir()? Of course this assumes that the security label >> genuinely isn't needed in this case (and not requesting it doesn't >> bypass access controls or break something on the server side), and we >> don't screw up some NFS client side cache by *not* fetching the >> security label attribute. >> >> Is this remotely close to workable, or am I missing something fundamental? >> > > No this is not going to work, as NFS requires labels when labels are > indeed needed by the LSM. What I'm looking for is an optimization. > What we have is functionality correct but performance might suffer for > the standard case of NFSv4.2 seclabel enabled server and clients that > don't care about seclabels. Initial thought: We should ask linux-nfs for help with this. I've added them to the Cc: list. Olga, are you asking if the kernel NFS client module can somehow find out whether the rest of the kernel is configured to care about security labels before it forms an NFSv4 READDIR or LOOKUP request? I would certainly like to take the security label query out of every LOOKUP operation if that is feasible! -- Chuck Lever chucklever@gmail.com