On Wed, 2022-12-21 at 19:55 -0500, Paul Moore wrote:

On Wed, Dec 21, 2022 at 4:54 AM Roberto Sassu
[off-list ref] wrote:

quoted

On 12/20/2022 9:44 PM, Paul Moore wrote:

quoted

On Fri, Dec 16, 2022 at 5:24 AM Roberto Sassu
[off-list ref] wrote:

quoted

Ok, let me try to complete the solution for the issues Lorenz pointed
out. Here I discuss only the system call side of access.

I was thinking on the meaning of the permissions on the inode of a
pinned eBPF object. Given that the object exists without pinning, this
double check of permissions first on the inode and then on the object
to me looks very confusing.

So, here is a proposal: what if read and write in the context of
pinning don't refer to accessing the eBPF object itself but to the
ability to read the association between inode and eBPF object or to
write/replace the association with a different eBPF object (I guess not
supported now).

We continue to do access control only at the time a requestor asks for
a fd. Currently there is only MAC, but we can add DAC and POSIX ACL too
(Andrii wanted to give read permission to a specific group). The owner
is who created the eBPF object and who can decide (for DAC and ACL) who
can access that object.

The requestor obtains a fd with modes depending on what was granted. Fd
modes (current behavior) give the requestor the ability to do certain
operations. It is responsibility of the function performing the
operation on an eBPF object to check the fd modes first.

It does not matter if the eBPF object is accessed through ID or inode,
access control is solely based on who is accessing the object, who
created it and the object permissions. *_GET_FD_BY_ID and OBJ_GET
operations will have the same access control.

With my new proposal, once an eBPF object is pinned the owner or
whoever can access the inode could do chown/chmod. But this does not
have effect on the permissions of the object. It changes only who can
retrieve the association with the eBPF object itself.

Just to make sure I understand you correctly, you're suggesting that
the access modes assigned to a pinned map's fd are simply what is
requested by the caller, and don't necessarily represent the access
control modes of the underlying map, is that correct?  That seems a

The fd modes don't necessarily represent the access control modes of the
inode the map is pinned to. But they surely represent the access control
modes of the map object itself.

The access control modes of the inode tell if the requestor is able to
retrieve the map from it, before accessing the map is attempted. But,
even if the request is granted (i.e. the inode has read permission), the
requestor has still to pass access control on the map object, which is
separate.

Okay, good.  That should work.

quoted

Fd modes are bound to the map access modes, but not necessarily bound to
the inode access modes (fd with write mode, on an inode with only read
permission). Fd modes are later enforced by map operations by checking
the compatibility of the operation (e.g. read-like operation requires fd
read mode).

The last point is what it means getting a fd on the inode itself. It is
possible, because inodes could have seq_file operations. Thus, one could
dump the map content by just reading from the inode.

Gotcha, yes, that would be bad.

quoted

Here, I suggest that we still do two separate checks. One is for the
open(), done by the VFS, and the other to access the map object. Not
having read permission on the inode means that the map content cannot be
dumped. But, having read permission on the inode does not imply the
ability to do it (still the map object check has to be passed).

That makes sense to me.

Andrii, Lorenz, what do you think about the new interpretation of the
permissions of the inode of a pinned map?

Thanks

Roberto