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

[Casey Schaufler <casey@schaufler-ca.com>]

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
justify.

>
> 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(-)
>