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 for Android: free password hash cracker in your pocket

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

Message-ID: <A9CEA82D-DEC7-4F4F-AF16-68CFF5DA203A@belouin.fr>
Date:   Sat, 21 Oct 2017 21:40:14 +0200
From:   Nicolas Belouin <nicolas@...ouin.fr>
To:     Nick Kralevich <nnk@...gle.com>
CC:     Alexander Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
        linux-api@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [kernel-hardening] [PATCH] fs: Use CAP_DAC_OVERRIDE to allow for file dedupe



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.

>
>>         u16 count = same->dest_count;
>>         struct file *dst_file;
>>         loff_t dst_off;
>> --
>> 2.14.2
>>

Nicolas