From: Alexey Gladkov <legion@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
containers@lists.linux.dev, linux-fsdevel@vger.kernel.org,
Alexey Dobriyan <adobriyan@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>, Val Cowan <vcowan@redhat.com>
Subject: Re: [RFC PATCH v1 0/6] proc: Add allowlist for procfs files
Date: Tue, 31 Jan 2023 14:53:46 +0100 [thread overview]
Message-ID: <Y9kdaty9lP2gu510@example.org> (raw)
In-Reply-To: <Y9KCkuGqyr5T13XN@example.org>
On Thu, Jan 26, 2023 at 02:39:30PM +0100, Alexey Gladkov wrote:
> > In general, such flexibility belongs into userspace imho.
> >
> > Frankly, if that is really required it would almost make more sense to
> > be able to attach a new bpf program type to procfs that would allow to
> > filter procfs entries. Then the filter could be done purely in
> > userspace. If signed bpf lands one could then even ship signed programs
> > that are attachable by userns root.
>
> I'll ask the podman developers how much more comfortable they would be
> using bpf to control file visibility in procfs. thanks for the idea.
I write for history.
After digging into eBPF, I came to the conclusion that nothing needs to be
done in kernel space. Access can be controlled via "lsm/file_open". Access
can be controlled per cgroup or per mountpoint, depending on the task.
Each project has its own choice.
Many thanks for pointing out eBPF.
--
Rgrds, legion
next prev parent reply other threads:[~2023-01-31 13:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-25 15:28 [RFC PATCH v1 0/6] proc: Add allowlist for procfs files Alexey Gladkov
2023-01-25 15:28 ` [RFC PATCH v1 1/6] proc: Fix separator for subset option Alexey Gladkov
2023-01-25 15:28 ` [RFC PATCH v1 2/6] proc: Add allowlist to control access to procfs files Alexey Gladkov
2023-01-25 23:36 ` Andrew Morton
2023-01-26 11:13 ` Alexey Gladkov
2023-01-25 23:36 ` Andrew Morton
2023-01-25 15:28 ` [RFC PATCH v1 3/6] proc: Check that subset= option has been set Alexey Gladkov
2023-01-25 15:28 ` [RFC PATCH v1 4/6] proc: Allow to use the allowlist filter in userns Alexey Gladkov
2023-01-25 15:28 ` [RFC PATCH v1 5/6] proc: Validate incoming allowlist Alexey Gladkov
2023-01-28 16:32 ` kernel test robot
2023-01-25 15:28 ` [RFC PATCH v1 6/6] doc: proc: Add description of subset=allowlist Alexey Gladkov
2023-01-25 23:36 ` [RFC PATCH v1 0/6] proc: Add allowlist for procfs files Andrew Morton
2023-01-26 10:16 ` Christian Brauner
2023-01-26 13:39 ` Alexey Gladkov
2023-01-31 13:53 ` Alexey Gladkov [this message]
2023-01-26 12:30 ` Alexey Gladkov
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=Y9kdaty9lP2gu510@example.org \
--to=legion@kernel.org \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=containers@lists.linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vcowan@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.