linux-ext4 - Check for CAP_SYS_ADMIN before thaw/freeze block device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAM6ytZooJ9jJp4rZn4HRjh7RANrB981xVkyOTYWZPadQBa68nQ@mail.gmail.com>
Date:   Sun, 30 May 2021 22:20:48 +0800
From:   tianyu zhou <tyjoe.linux@...il.com>
To:     "Theodore Ts'o" <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        linux-ext4@...r.kernel.org
Subject: Check for CAP_SYS_ADMIN before thaw/freeze block device

Hi, from commit "fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and
thaw filesystems" (SHA: f3f1a18330ac1b717cd7a32adff38d965f365aa2), I
learned that "The user in control of a super block should be allowed
to freeze and thaw it".

However, unlike ioctl_fsthaw and ioctl_fsfreeze which use ns_capable
to check CAP_SYS_ADMIN in super block's user ns, function thaw_bdev
and freeze_bdev in fs/block_dev.c also do the same thaw/freeze
operation to super block, with no check for CAP_SYS_ADMIN.

I searched these two functions' callers, and found there are check for
CAP_SYS_ADMIN before the callers call them, however, the check is
using capable which is inconsistent with the the commit I mentioned
earlier.

Here is an example:
-----------------------------
// fs/ext4/ioctl.c
static int ext4_shutdown(struct super_block *sb, unsigned long arg)
{
    ...
    if (!capable(CAP_SYS_ADMIN))
        return -EPERM;
    ...
    switch (flags) {
        case EXT4_GOING_FLAGS_DEFAULT:
            freeze_bdev(sb->s_bdev);
-----------------------------

So it is possible to change this kind of CAP_SYS_ADMIN check from
capable() to ns_capable() to keep consistency with the former commit?

Thanks!

Best regards,
Tianyu