From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: David Stevens <stevensd@chromium.org>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] PCI: sysfs: add bypass for config read admin check
Date: Wed, 6 Apr 2022 10:09:33 +0200 [thread overview]
Message-ID: <Yk1KveOnYfSrUJLD@kroah.com> (raw)
In-Reply-To: <20220406071131.2930035-1-stevensd@google.com>
On Wed, Apr 06, 2022 at 04:11:31PM +0900, David Stevens wrote:
> From: David Stevens <stevensd@chromium.org>
>
> Add a moduleparam that can be set to bypass the check that limits users
> without CAP_SYS_ADMIN to only being able to read the first 64 bytes of
> the config space. This allows systems without problematic hardware to be
> configured to allow users without CAP_SYS_ADMIN to read PCI
> capabilities.
>
> Signed-off-by: David Stevens <stevensd@chromium.org>
> ---
> drivers/pci/pci-sysfs.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index 602f0fb0b007..162423b3c052 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -28,10 +28,17 @@
> #include <linux/pm_runtime.h>
> #include <linux/msi.h>
> #include <linux/of.h>
> +#include <linux/moduleparam.h>
> #include "pci.h"
>
> static int sysfs_initialized; /* = 0 */
>
> +static bool allow_unsafe_config_reads;
> +module_param_named(allow_unsafe_config_reads,
> + allow_unsafe_config_reads, bool, 0644);
> +MODULE_PARM_DESC(allow_unsafe_config_reads,
> + "Enable full read access to config space without CAP_SYS_ADMIN.");
No, this is not the 1990's, please do not add system-wide module
parameters like this. Especially ones that circumvent security
protections.
Also, where did you document this new option?
Why not just add this to a LSM instead?
> /* show configuration fields */
> #define pci_config_attr(field, format_string) \
> static ssize_t \
> @@ -696,7 +703,8 @@ static ssize_t pci_read_config(struct file *filp, struct kobject *kobj,
> u8 *data = (u8 *) buf;
>
> /* Several chips lock up trying to read undefined config space */
> - if (file_ns_capable(filp, &init_user_ns, CAP_SYS_ADMIN))
> + if (allow_unsafe_config_reads ||
> + file_ns_capable(filp, &init_user_ns, CAP_SYS_ADMIN))
This feels really dangerous. What benifit are you getting here by
allowing an unpriviliged user to read this information?
What userspace problem are you trying to solve here that deserves this
change?
thanks,
greg k-h
next prev parent reply other threads:[~2022-04-06 12:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-06 7:11 [RFC] PCI: sysfs: add bypass for config read admin check David Stevens
2022-04-06 8:09 ` Greg Kroah-Hartman [this message]
2022-04-06 13:13 ` Pali Rohár
2022-04-12 7:51 ` David Stevens
2022-04-12 9:57 ` Greg Kroah-Hartman
2022-04-06 11:17 ` Bjorn Helgaas
2022-04-08 15:50 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yk1KveOnYfSrUJLD@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=stevensd@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox