linux-kernel - Re: [kernel-hardening] [PATCH] fs: Use CAP_DAC

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALCETrVaAOaQgTGiTnSoRiEX4oj1BOiKdfjsd+O8-zQd_vHk4Q@mail.gmail.com>
Date:   Thu, 26 Oct 2017 00:54:42 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Nicolas Belouin <nicolas@...ouin.fr>
Cc:     Nick Kralevich <nnk@...gle.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>
Subject: Re: [kernel-hardening] [PATCH] fs: Use CAP_DAC_OVERRIDE to allow for
 file dedupe

On Sat, Oct 21, 2017 at 12:40 PM, Nicolas Belouin <nicolas@...ouin.fr> wrote:
>
>
> On October 21, 2017 4:08:31 PM GMT+02:00, Nick Kralevich <nnk@...gle.com> wrote:
>>On Sat, Oct 21, 2017 at 6:28 AM, Nicolas Belouin <nicolas@...ouin.fr>
>>wrote:
>>> In its current implementation the check is against CAP_SYS_ADMIN,
>>> however this capability is bloated and inapropriate for this use.
>>> Indeed the check aims to avoid dedupe against non writable files,
>>> falling directly in the use case of CAP_DAC_OVERRIDE.
>>>
>>> Signed-off-by: Nicolas Belouin <nicolas@...ouin.fr>
>>> ---
>>>  fs/read_write.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/fs/read_write.c b/fs/read_write.c
>>> index f0d4b16873e8..43cc7e84e29e 100644
>>> --- a/fs/read_write.c
>>> +++ b/fs/read_write.c
>>> @@ -1965,7 +1965,7 @@ int vfs_dedupe_file_range(struct file *file,
>>struct file_dedupe_range *same)
>>>         u64 len;
>>>         int i;
>>>         int ret;
>>> -       bool is_admin = capable(CAP_SYS_ADMIN);
>>> +       bool is_admin = capable(CAP_SYS_ADMIN) ||
>>capable(CAP_DAC_OVERRIDE);
>>
>>Can you please reverse the order of the checks? In particular, on an
>>SELinux based system, a capable() call generates an SELinux denial,
>>and people often instinctively allow the first operation performed.
>>Reordering the elements will ensure that the CAP_DAC_OVERRIDE denial
>>(least permissive) is generated first.
>
> Will do in the v2 of every concerned patch.
>

That's still a bit wrong because of how audit works.  What you really want is:

bool have_either_global_cap(int cap1, int cap2);

where, if neither cap is available, the audit message references cap1
and not cap2.  Ditto for have_either_ns_cap().

--Andy