From: David Miller <davem@davemloft.net>
To: maheshb@google.com
Cc: gregkh@linuxfoundation.org, mahesh@bandewar.net,
mingo@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, ebiederm@xmission.com,
keescook@chromium.org, edumazet@google.com
Subject: Re: [PATCH] kmod: don't load module unless req process has CAP_SYS_MODULE
Date: Mon, 15 May 2017 09:48:23 -0400 (EDT) [thread overview]
Message-ID: <20170515.094823.1069232190223991895.davem@davemloft.net> (raw)
In-Reply-To: <CAF2d9jh6zARipRGM92drOjjrpicF6177cnUf=6oHbR9tHX1ObA@mail.gmail.com>
From: Mahesh Bandewar (महेश बंडेवार) <maheshb@google.com>
Date: Sun, 14 May 2017 19:42:08 -0700
> Any module when loaded gets loaded system-wide as we can't allow
> module loading per-ns. To validate the behavior I was comparing it
> with insmod/modprobe, if that doesn't allow because of lack of this
> capability in default-ns, then this *indirect* method of loading
> module should not allow the same action and the behavior should be
> consistent. So with that logic if userspace asks for a random
> char-device if insmod/modprobe cannot load it, then this method should
> not load it either for the consistency, right?
A lot of us worry that the are decades of precedence for the current
behavior.
If the user asks for bridge statistics and the bridge module isn't
loaded, it does get loaded and they see the statistics.
Same goes for opening socket types of various protocols.
Things really can break if we stop doing this.
prev parent reply other threads:[~2017-05-15 13:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-12 23:22 [PATCH] kmod: don't load module unless req process has CAP_SYS_MODULE Mahesh Bandewar
2017-05-14 10:45 ` Greg Kroah-Hartman
2017-05-14 13:57 ` Eric W. Biederman
2017-05-15 6:10 ` Greg Kroah-Hartman
2017-05-15 13:52 ` David Miller
2017-05-15 17:59 ` Mahesh Bandewar (महेश बंडेवार)
2017-05-15 18:14 ` David Miller
2017-05-15 18:20 ` Eric W. Biederman
2017-05-15 19:59 ` Florian Westphal
2017-05-15 2:42 ` Mahesh Bandewar (महेश बंडेवार)
2017-05-15 6:10 ` Greg Kroah-Hartman
2017-05-15 13:12 ` Eric Dumazet
2017-05-15 17:07 ` Kees Cook
2017-05-15 13:48 ` David Miller [this message]
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=20170515.094823.1069232190223991895.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mahesh@bandewar.net \
--cc=maheshb@google.com \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).