From: "Toke Høiland-Jørgensen" <toke@kernel.org>
To: Roberto Sassu <roberto.sassu@huaweicloud.com>,
Lorenz Bauer <oss@lmb.io>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>
Cc: bpf@vger.kernel.org, linux-security-module@vger.kernel.org
Subject: Re: Closing the BPF map permission loophole
Date: Wed, 28 Sep 2022 12:33:48 +0200 [thread overview]
Message-ID: <87mtajss8j.fsf@toke.dk> (raw)
In-Reply-To: <6e142c3526df693abfab6e1293a27828267cc45e.camel@huaweicloud.com>
Roberto Sassu <roberto.sassu@huaweicloud.com> writes:
> On Wed, 2022-09-28 at 09:52 +0100, Lorenz Bauer wrote:
>> On Mon, 26 Sep 2022, at 17:18, Roberto Sassu wrote:
>> > Uhm, if I get what you mean, you would like to add DAC controls to
>> > the
>> > pinned map to decide if you can get a fd and with which modes.
>> >
>> > The problem I see is that a map exists regardless of the pinned
>> > path
>> > (just by ID).
>>
>> Can you spell this out for me? I imagine you're talking about
>> MAP_GET_FD_BY_ID, but that is CAP_SYS_ADMIN only, right? Not great
>> maybe, but no gaping hole IMO.
>
> +linux-security-module ML (they could be interested in this topic as
> well)
>
> Good to know! I didn't realize it before.
>
> I figured out better what you mean by escalating privileges.
>
> Pin a read-only fd, get a read-write fd from the pinned path.
>
> What you want to do is, if I pin a read-only fd, I should get read-only
> fds too, right?
>
> I think here there could be different views. From my perspective,
> pinning is just creating a new link to an existing object. Accessing
> the link does not imply being able to access the object itself (the
> same happens for files).
>
> I understand what you want to achieve. If I have to choose a solution,
> that would be doing something similar to files, i.e. add owner and mode
> information to the bpf_map structure (m_uid, m_gid, m_mode). We could
> add the MAP_CHMOD and MAP_CHOWN operations to the bpf() system call to
> modify the new fields.
>
> When you pin the map, the inode will get the owner and mode from
> bpf_map. bpf_obj_get() will then do DAC-style verification similar to
> MAC-style verification (with security_bpf_map()).
As someone pointed out during the discussing at LPC, this will
effectively allow a user to create files owned by someone else, which is
probably not a good idea either from a security PoV. (I.e., user A pins
map owned by user B, so A creates a file owned by B).
-Toke
next prev parent reply other threads:[~2022-09-28 10:33 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-15 10:30 Closing the BPF map permission loophole Lorenz Bauer
2022-09-16 3:03 ` Kumar Kartikeya Dwivedi
2022-09-22 14:57 ` Lorenz Bauer
2022-09-17 15:42 ` Stanislav Fomichev
2022-09-21 16:32 ` Roberto Sassu
2022-09-22 14:47 ` Lorenz Bauer
2022-09-22 15:39 ` Roberto Sassu
2022-09-22 16:21 ` Lorenz Bauer
2022-09-23 7:39 ` Roberto Sassu
2022-09-26 15:35 ` Lorenz Bauer
2022-09-26 16:18 ` Roberto Sassu
2022-09-28 8:52 ` Lorenz Bauer
2022-09-28 9:42 ` Roberto Sassu
2022-09-28 10:33 ` Toke Høiland-Jørgensen [this message]
2022-09-28 11:23 ` Roberto Sassu
2022-09-29 0:24 ` Paul Moore
2022-09-29 7:54 ` Roberto Sassu
2022-09-29 15:27 ` Casey Schaufler
2022-09-30 7:42 ` Roberto Sassu
2022-09-29 22:30 ` Paul Moore
2022-09-30 9:56 ` Roberto Sassu
2022-09-30 20:43 ` Paul Moore
2022-10-04 8:03 ` Roberto Sassu
2022-09-22 16:29 ` Lorenz Bauer
2022-09-22 23:21 ` Hao Luo
2022-09-26 15:41 ` Lorenz Bauer
2022-09-26 18:39 ` Hao Luo
2022-09-28 8:54 ` Lorenz Bauer
2022-10-06 7:15 ` Roberto Sassu
2022-10-27 16:54 ` Andrii Nakryiko
2022-10-28 6:27 ` Greg KH
2022-10-28 17:17 ` Andrii Nakryiko
2022-10-29 11:18 ` Lorenz Bauer
2022-10-31 11:53 ` Roberto Sassu
2022-11-04 21:10 ` Andrii Nakryiko
2022-11-07 12:11 ` Roberto Sassu
2022-12-12 16:10 ` Roberto Sassu
2022-12-12 17:07 ` Alexei Starovoitov
2022-12-12 18:19 ` Roberto Sassu
2022-12-16 10:23 ` Roberto Sassu
2022-12-20 20:44 ` Paul Moore
2022-12-21 9:53 ` Roberto Sassu
2022-12-22 0:55 ` Paul Moore
2023-01-10 9:11 ` Roberto Sassu
2023-01-13 23:44 ` Andrii Nakryiko
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=87mtajss8j.fsf@toke.dk \
--to=toke@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kpsingh@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=oss@lmb.io \
--cc=roberto.sassu@huaweicloud.com \
--cc=sdf@google.com \
/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.