maxgio92 (@[email protected])

Finer-grained BPF tokens - lwn.net/Articles/947173/ 💻 BPF programs can perform privileged operations and thus, their loading and run operations must be privileged themselves. Previously, developers have struggled to limit these privileges and a proposal of a BPF token encountered opposition. 🔑 Initially, the ability to load BPF programs was limited to processes with the CAP_SYS_ADMIN capability, equating to root access. But it was realized that this gave too much power. In response, the CAP_BPF capability was introduced to manage BPF operations, but this still granted more permission than desired. 👀 There's profound interest in finding ways to refine what processes can do with BPF. Several methods have been tried and rejected. A BPF token was seen as a promising solution, as it has the potential to grant rights to load BPF programs without overstepping bounds. 🚧 Running the needed process with limited privilege within a container has been a standard solution. But, certain BPF-related operations cannot be contained in this way, making CAP_BPF within a user namespace not an adequate solution. 📜 The proposed BPF tokens assign CAP_BPF capability within a container. Tokens are tied to a specific instance of the BPF filesystem and a user namespace, limiting any potential misuse. 🔧 The BPF filesystem needs to be augmented with a new set of mount options to manage the interaction with BPF tokens properly. 📚 BPF_TOKEN_CREATE can then be used to create a new BPF token. The token will be associated forever with the BPF filesystem and the user namespace. 🏷️ This token can then be used with any bpf() calls. It is important to note that possessing the token does not guarantee permission. The process must still have the required capabilities. 🎁 With this implementation, a process within a user namespace can perform BPF operations, provided it owns a valid token, the token permits the operation, and the process has the requisite capabilities.