Re: [PATCH 0/2] capability: Introduce CAP_BLOCK_ADMIN

From: Casey Schaufler
Date: Thu May 11 2023 - 12:17:36 EST

On 5/11/2023 12:05 AM, Tianjia Zhang wrote:
> Separated fine-grained capability CAP_BLOCK_ADMIN from CAP_SYS_ADMIN.
> For backward compatibility, the CAP_BLOCK_ADMIN capability is included
> within CAP_SYS_ADMIN.
> Some database products rely on shared storage to complete the
> write-once-read-multiple and write-multiple-read-multiple functions.
> When HA occurs, they rely on the PR (Persistent Reservations) protocol
> provided by the storage layer to manage block device permissions to
> ensure data correctness.
> CAP_SYS_ADMIN is required in the PR protocol implementation of existing
> block devices in the Linux kernel, which has too many sensitive
> permissions, which may lead to risks such as container escape. The
> kernel needs to provide more fine-grained permission management like
> CAP_NET_ADMIN to avoid online products directly relying on root to run.
> CAP_BLOCK_ADMIN can also provide support for other block device
> operations that require CAP_SYS_ADMIN capabilities in the future,
> ensuring that applications run with least privilege.

Can you demonstrate that there are cases where a program that needs
CAP_BLOCK_ADMIN does not also require CAP_SYS_ADMIN for other operations?
How much of what's allowed by CAP_SYS_ADMIN would be allowed by
CAP_BLOCK_ADMIN? If use of a new capability is rare it's difficult to

> Tianjia Zhang (2):
> capability: Introduce CAP_BLOCK_ADMIN
> block: use block_admin_capable() for Persistent Reservations
> block/ioctl.c | 10 +++++-----
> include/linux/capability.h | 5 +++++
> include/uapi/linux/capability.h | 7 ++++++-
> security/selinux/include/classmap.h | 4 ++--
> 4 files changed, 18 insertions(+), 8 deletions(-)