On Wed, Dec 21, 2022 at 4:54 AM Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > On 12/20/2022 9:44 PM, Paul Moore wrote: > > On Fri, Dec 16, 2022 at 5:24 AM Roberto Sassu > > <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > >> 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. > 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. > 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. -- paul-moore.com
