Message ID | 20221013223654.659758-6-keescook@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp510804wrs; Thu, 13 Oct 2022 15:39:54 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5DaSX0pospmEh+VAdP4rHaszBS66mnFavMhXF2IByQlZ3bL6og39obT+iZmFujEpw5UKB+ X-Received: by 2002:a05:6402:27c8:b0:458:ecf7:7248 with SMTP id c8-20020a05640227c800b00458ecf77248mr1737198ede.67.1665700793836; Thu, 13 Oct 2022 15:39:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665700793; cv=none; d=google.com; s=arc-20160816; b=D7Z69it6BEN/dUDWecfWumWFkUKrjPa2idT/TIgPky7xdZEnFwHFzxcJT5b8AS6HdG G88lY3jsNqki6aC9RTwWYTJ6xvKmBNssaZFwDIm0XEBnWB6+Z/vzHf6gBb2MuHNzmUvL TPeNYFbOb20X7ZNBgsa18NHz0OljNCXKVvdaHo6ZkXULZqKNHl25AghuvlFpDWqqTRxr taYARB4g9QhViXj0GFwKzi/c85syszfAAK4XVmfaMR/P6ys/P2eIrLlMaIo1f4xzwGEc 5nv3yYMRXUr5wOarZtr+D8BFag9XfWL/9je2Qvq5a58pr4dfhchVg+mpSeGqUbTgRcFj MElw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=i0+hkpiHQzJ8+JNug0yAZuhS5yrr5xFtDUDfT1r5L18=; b=EEm2lN8fJs/PQxcZ9et4pJZLrPdDPlOxYZTs4CfWAYjww1FGut/fQEhxW1y6EFP14Y 9BJXZ69XVJLLeIMozVRBk2F53ntYsQeGI7MUVH97b3u4Bzw+yYcVAp4TuLlOk9OM37V+ URP8C+sr2XLLvEekNed2MWOTsbGW8yD4cYHWZD5+c9aOsubl67HJYeCuY5ZXTPsMokKq NfkR6nq7hcpZtOYaYRRH4ko3rQdu52yEF1zQZb/Jv5q5jXlsxNSFzgUzeUQ3XuIebRcS jO6BcbWYTmF6W5KgD7jgznShcizrlyGZ0NPvwkjj8LA7VNf1bPHGjOTa0mljZfpuVDL8 JlUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=QYx587gs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r11-20020a170906704b00b0078d44b51f66si671909ejj.1008.2022.10.13.15.39.27; Thu, 13 Oct 2022 15:39:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=QYx587gs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229894AbiJMWhl (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Thu, 13 Oct 2022 18:37:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229797AbiJMWhI (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 13 Oct 2022 18:37:08 -0400 Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1074153821 for <linux-kernel@vger.kernel.org>; Thu, 13 Oct 2022 15:37:02 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id r18so2741408pgr.12 for <linux-kernel@vger.kernel.org>; Thu, 13 Oct 2022 15:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=i0+hkpiHQzJ8+JNug0yAZuhS5yrr5xFtDUDfT1r5L18=; b=QYx587gsPoZ2Rt2D31lwneKBIE0nlruGRbmbSxEd/wU1/e+ZARKYeK3iBavfszJMpM 1rdsc3DARoEg5VnS/veGem8AflPWSHFlpLtT8GshvYDBN7qk5Mr4i5Pqa0foKF19eZSx b8TpbYuA0q39bY4XbbSsFmEZKiZC2QIMQjSrk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=i0+hkpiHQzJ8+JNug0yAZuhS5yrr5xFtDUDfT1r5L18=; b=c+FAsR/eMuUa15yhpnhXvI8Ek17iKV2hI0AnAkx70Hl6+2jEDw+lez56i5xjpl8ZDT hn+ysuhNqDNFuOnfvnT1upo6B3U3kgW7PJR6GJqTrK9lxVAiJ1EjCwGzOHziN4AUWSn/ d4z6P1pKP2jdxhc7EvXbmhjuO9044S+dXiQCVN7F2p50KL/ILWDII6kxV9ugTJ+5D8Ac oMfWRIy+M3HWz1hcqp5+xfk6P4UxfSrZhipXdlhsSJTx8ir72cVfEVJzht1XcgoWf7ML 2oe6stlBiU0TYEpVSnRMG5pAxFyFcNBzFPrjl6LM6uI6w7RopMv9FeTtunK3xi/4sYlM E4Cg== X-Gm-Message-State: ACrzQf0ZxsvYzDOcClxQUKWMNxMqAupnaIkZ5/6taqke5ndNUa//YdHR qFjmpjCEGPLDbWAy8DGAWvEydw== X-Received: by 2002:a05:6a00:2393:b0:566:813c:ae26 with SMTP id f19-20020a056a00239300b00566813cae26mr185199pfc.8.1665700621319; Thu, 13 Oct 2022 15:37:01 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id q6-20020a170902f78600b001769cfa5cd4sm356820pln.49.2022.10.13.15.36.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Oct 2022 15:37:00 -0700 (PDT) From: Kees Cook <keescook@chromium.org> To: Mimi Zohar <zohar@linux.ibm.com> Cc: Kees Cook <keescook@chromium.org>, John Johansen <john.johansen@canonical.com>, Paul Moore <paul@paul-moore.com>, James Morris <jmorris@namei.org>, "Serge E. Hallyn" <serge@hallyn.com>, linux-security-module@vger.kernel.org, =?utf-8?q?Micka=C3=ABl_Sala=C3=BCn?= <mic@digikod.net>, KP Singh <kpsingh@kernel.org>, Casey Schaufler <casey@schaufler-ca.com>, linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-hardening@vger.kernel.org Subject: [PATCH 6/9] fs: Introduce file_to_perms() helper Date: Thu, 13 Oct 2022 15:36:51 -0700 Message-Id: <20221013223654.659758-6-keescook@chromium.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221013222702.never.990-kees@kernel.org> References: <20221013222702.never.990-kees@kernel.org> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2624; h=from:subject; bh=kHSufPh8mIo/bjTRCkWIphPq0T9RFTX/D7KSIVqq6E4=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBjSJMFgxBLCCrCvM8fbbAU6HUNSc0X+NBZd2coINEr PLUeV+uJAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCY0iTBQAKCRCJcvTf3G3AJuVVD/ 9dmweB5gcNNSwinfSOe+1SYjVoMp4pO/YbGKyzqp9iSQDnAu53m7/BKTysFNovCaUKyEh7197U6MUp LUlQFWZ0CQWe0ka2lwW89FLpkV2OI0Bd6U3SUeprwQa2Xm1ttkhbUuoUCH+IPzzpntm5qSaJ99vZcS zymhCi9swcwU28oJ6sd46pKWNe8UCm1d19nZbAFtIX17D07kJ026Aj8ODCCy2P6nMrLAGUJmaLkx9r 0+pX3zQpYs64lI1r953yaxCB/BIlz1RJrnyT1mz8fGVAH55bKakonK2JEd9CRd8KGNa+kRc83RDhA4 lFPpkEh/aNMoSXbYKrfc8SkyyDTOXJ5vDZ2KCWLZdwQIpac0vqg1CLH9N2sm0W6TckUP7vPvOmOM4Z f5eTZrLB84wp0DHMJCXrRZO79S56OiUwLCarTCtv0f5BZpgnThuf6BYDrLC054KiryunDIv2oAklMu p0Khd4nmP2MDptUEyCH2zfVmqZu9uoljoXA/Ry+tm/0Az96oaddZz6DS+mNs/sI8Q/F7PVMSVWbgGP 3Xow9kjRWe1Gybq5wjsfkZS/r7XPQih8TCBKJY7MBEguI9la9e/RULiGW2vtROMTuQ20u2IoU9zcp4 bpHEEfkAQeBR301m7ACV50ZLukKFNsCdbLDykTL4Q/jWHPFmMvi0iMknRKZw== X-Developer-Key: i=keescook@chromium.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1746613875149623390?= X-GMAIL-MSGID: =?utf-8?q?1746613875149623390?= |
Series |
integrity: Move hooks into LSM
|
|
Commit Message
Kees Cook
Oct. 13, 2022, 10:36 p.m. UTC
Extract the logic used by LSM file hooks to be able to reconstruct the
access mode permissions from an open.
Cc: John Johansen <john.johansen@canonical.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: linux-security-module@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
include/linux/fs.h | 22 ++++++++++++++++++++++
security/apparmor/include/file.h | 18 ++++--------------
2 files changed, 26 insertions(+), 14 deletions(-)
Comments
On Thu, Oct 13, 2022 at 03:36:51PM -0700, Kees Cook wrote: > Extract the logic used by LSM file hooks to be able to reconstruct the > access mode permissions from an open. > > Cc: John Johansen <john.johansen@canonical.com> > Cc: Paul Moore <paul@paul-moore.com> > Cc: James Morris <jmorris@namei.org> > Cc: "Serge E. Hallyn" <serge@hallyn.com> > Cc: linux-security-module@vger.kernel.org > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > include/linux/fs.h | 22 ++++++++++++++++++++++ > security/apparmor/include/file.h | 18 ++++-------------- > 2 files changed, 26 insertions(+), 14 deletions(-) > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 9eced4cc286e..814f10d4132e 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -993,6 +993,28 @@ static inline struct file *get_file(struct file *f) > #define get_file_rcu(x) atomic_long_inc_not_zero(&(x)->f_count) > #define file_count(x) atomic_long_read(&(x)->f_count) > > +/* Calculate the basic MAY_* flags needed for a given file. */ > +static inline u8 file_to_perms(struct file *file) As long as there aren't multiple users of this and especially none in the vfs proper please don't move this into fs.h. It's overloaded enough as it is and we have vague plans on splitting it further in the future.
On Tue, Oct 18, 2022 at 04:10:37PM +0200, Christian Brauner wrote: > On Thu, Oct 13, 2022 at 03:36:51PM -0700, Kees Cook wrote: > > Extract the logic used by LSM file hooks to be able to reconstruct the > > access mode permissions from an open. > > > > Cc: John Johansen <john.johansen@canonical.com> > > Cc: Paul Moore <paul@paul-moore.com> > > Cc: James Morris <jmorris@namei.org> > > Cc: "Serge E. Hallyn" <serge@hallyn.com> > > Cc: linux-security-module@vger.kernel.org > > Signed-off-by: Kees Cook <keescook@chromium.org> > > --- > > include/linux/fs.h | 22 ++++++++++++++++++++++ > > security/apparmor/include/file.h | 18 ++++-------------- > > 2 files changed, 26 insertions(+), 14 deletions(-) > > > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > index 9eced4cc286e..814f10d4132e 100644 > > --- a/include/linux/fs.h > > +++ b/include/linux/fs.h > > @@ -993,6 +993,28 @@ static inline struct file *get_file(struct file *f) > > #define get_file_rcu(x) atomic_long_inc_not_zero(&(x)->f_count) > > #define file_count(x) atomic_long_read(&(x)->f_count) > > > > +/* Calculate the basic MAY_* flags needed for a given file. */ > > +static inline u8 file_to_perms(struct file *file) > > As long as there aren't multiple users of this and especially none in > the vfs proper please don't move this into fs.h. It's overloaded enough > as it is and we have vague plans on splitting it further in the future. Sure -- this can live in a security .h file somewhere.
On 10/13/2022 3:36 PM, Kees Cook wrote: > Extract the logic used by LSM file hooks to be able to reconstruct the > access mode permissions from an open. > > Cc: John Johansen <john.johansen@canonical.com> > Cc: Paul Moore <paul@paul-moore.com> > Cc: James Morris <jmorris@namei.org> > Cc: "Serge E. Hallyn" <serge@hallyn.com> > Cc: linux-security-module@vger.kernel.org > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > include/linux/fs.h | 22 ++++++++++++++++++++++ > security/apparmor/include/file.h | 18 ++++-------------- > 2 files changed, 26 insertions(+), 14 deletions(-) Smack uses its own definitions for MAY_SOMETHING. Making AppArmor's values global is going to clash. If you want to do this there needs to be a grand consolidation. It could go in security/lsm_hooks.h. I can't see anyone other than Smack wanting MAY_LOCK, so I can't say the concept really makes much sense. > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 9eced4cc286e..814f10d4132e 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -993,6 +993,28 @@ static inline struct file *get_file(struct file *f) > #define get_file_rcu(x) atomic_long_inc_not_zero(&(x)->f_count) > #define file_count(x) atomic_long_read(&(x)->f_count) > > +/* Calculate the basic MAY_* flags needed for a given file. */ > +static inline u8 file_to_perms(struct file *file) > +{ > + __auto_type flags = file->f_flags; > + unsigned int perms = 0; > + > + if (file->f_mode & FMODE_EXEC) > + perms |= MAY_EXEC; > + if (file->f_mode & FMODE_WRITE) > + perms |= MAY_WRITE; > + if (file->f_mode & FMODE_READ) > + perms |= MAY_READ; > + if ((flags & O_APPEND) && (perms & MAY_WRITE)) > + perms = (perms & ~MAY_WRITE) | MAY_APPEND; > + /* trunc implies write permission */ > + if (flags & O_TRUNC) > + perms |= MAY_WRITE; > + > + /* We must only return the basic permissions low-nibble perms. */ > + return (perms | (MAY_EXEC | MAY_WRITE | MAY_READ | MAY_APPEND)); > +} > + > #define MAX_NON_LFS ((1UL<<31) - 1) > > /* Page cache limit. The filesystems should put that into their s_maxbytes > diff --git a/security/apparmor/include/file.h b/security/apparmor/include/file.h > index 029cb20e322d..505d6da02af3 100644 > --- a/security/apparmor/include/file.h > +++ b/security/apparmor/include/file.h > @@ -218,20 +218,10 @@ static inline void aa_free_file_rules(struct aa_file_rules *rules) > */ > static inline u32 aa_map_file_to_perms(struct file *file) > { > - int flags = file->f_flags; > - u32 perms = 0; > - > - if (file->f_mode & FMODE_WRITE) > - perms |= MAY_WRITE; > - if (file->f_mode & FMODE_READ) > - perms |= MAY_READ; > - > - if ((flags & O_APPEND) && (perms & MAY_WRITE)) > - perms = (perms & ~MAY_WRITE) | MAY_APPEND; > - /* trunc implies write permission */ > - if (flags & O_TRUNC) > - perms |= MAY_WRITE; > - if (flags & O_CREAT) > + u32 perms = file_to_perms(file); > + > + /* Also want to check O_CREAT */ > + if (file->f_flags & O_CREAT) > perms |= AA_MAY_CREATE; > > return perms;
On Thu, Oct 20, 2022 at 10:29:08AM -0700, Casey Schaufler wrote: > On 10/13/2022 3:36 PM, Kees Cook wrote: > > Extract the logic used by LSM file hooks to be able to reconstruct the > > access mode permissions from an open. > > > > Cc: John Johansen <john.johansen@canonical.com> > > Cc: Paul Moore <paul@paul-moore.com> > > Cc: James Morris <jmorris@namei.org> > > Cc: "Serge E. Hallyn" <serge@hallyn.com> > > Cc: linux-security-module@vger.kernel.org > > Signed-off-by: Kees Cook <keescook@chromium.org> > > --- > > include/linux/fs.h | 22 ++++++++++++++++++++++ > > security/apparmor/include/file.h | 18 ++++-------------- > > 2 files changed, 26 insertions(+), 14 deletions(-) > > Smack uses its own definitions for MAY_SOMETHING. Making > AppArmor's values global is going to clash. If you want to > do this there needs to be a grand consolidation. It could > go in security/lsm_hooks.h. I can't see anyone other than > Smack wanting MAY_LOCK, so I can't say the concept really > makes much sense. I left AppArmor's special ones in apparmor/. This only lifts the common pre-existing global VFS MAY_* flags. (And only the low nibble's worth).
diff --git a/include/linux/fs.h b/include/linux/fs.h index 9eced4cc286e..814f10d4132e 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -993,6 +993,28 @@ static inline struct file *get_file(struct file *f) #define get_file_rcu(x) atomic_long_inc_not_zero(&(x)->f_count) #define file_count(x) atomic_long_read(&(x)->f_count) +/* Calculate the basic MAY_* flags needed for a given file. */ +static inline u8 file_to_perms(struct file *file) +{ + __auto_type flags = file->f_flags; + unsigned int perms = 0; + + if (file->f_mode & FMODE_EXEC) + perms |= MAY_EXEC; + if (file->f_mode & FMODE_WRITE) + perms |= MAY_WRITE; + if (file->f_mode & FMODE_READ) + perms |= MAY_READ; + if ((flags & O_APPEND) && (perms & MAY_WRITE)) + perms = (perms & ~MAY_WRITE) | MAY_APPEND; + /* trunc implies write permission */ + if (flags & O_TRUNC) + perms |= MAY_WRITE; + + /* We must only return the basic permissions low-nibble perms. */ + return (perms | (MAY_EXEC | MAY_WRITE | MAY_READ | MAY_APPEND)); +} + #define MAX_NON_LFS ((1UL<<31) - 1) /* Page cache limit. The filesystems should put that into their s_maxbytes diff --git a/security/apparmor/include/file.h b/security/apparmor/include/file.h index 029cb20e322d..505d6da02af3 100644 --- a/security/apparmor/include/file.h +++ b/security/apparmor/include/file.h @@ -218,20 +218,10 @@ static inline void aa_free_file_rules(struct aa_file_rules *rules) */ static inline u32 aa_map_file_to_perms(struct file *file) { - int flags = file->f_flags; - u32 perms = 0; - - if (file->f_mode & FMODE_WRITE) - perms |= MAY_WRITE; - if (file->f_mode & FMODE_READ) - perms |= MAY_READ; - - if ((flags & O_APPEND) && (perms & MAY_WRITE)) - perms = (perms & ~MAY_WRITE) | MAY_APPEND; - /* trunc implies write permission */ - if (flags & O_TRUNC) - perms |= MAY_WRITE; - if (flags & O_CREAT) + u32 perms = file_to_perms(file); + + /* Also want to check O_CREAT */ + if (file->f_flags & O_CREAT) perms |= AA_MAY_CREATE; return perms;