linux-kernel - Re: [PATCH v8 2/3] mm: add a field to store names for private anonymous memory

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]

Date:   Mon, 30 Aug 2021 10:12:18 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Suren Baghdasaryan <surenb@...gle.com>,
        Kees Cook <keescook@...omium.org>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Colin Cross <ccross@...gle.com>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Michal Hocko <mhocko@...e.com>,
        Dave Hansen <dave.hansen@...el.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Johannes Weiner <hannes@...xchg.org>,
        Jonathan Corbet <corbet@....net>,
        Al Viro <viro@...iv.linux.org.uk>,
        Randy Dunlap <rdunlap@...radead.org>,
        Kalesh Singh <kaleshsingh@...gle.com>,
        Peter Xu <peterx@...hat.com>, rppt@...nel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Catalin Marinas <catalin.marinas@....com>,
        vincenzo.frascino@....com,
        Chinwen Chang (張錦文) 
        <chinwen.chang@...iatek.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Jann Horn <jannh@...gle.com>, apopple@...dia.com,
        John Hubbard <jhubbard@...dia.com>,
        Yu Zhao <yuzhao@...gle.com>, Will Deacon <will@...nel.org>,
        fenghua.yu@...el.com, thunder.leizhen@...wei.com,
        Hugh Dickins <hughd@...gle.com>, feng.tang@...el.com,
        Jason Gunthorpe <jgg@...pe.ca>, Roman Gushchin <guro@...com>,
        Thomas Gleixner <tglx@...utronix.de>, krisman@...labora.com,
        chris.hyser@...cle.com, Peter Collingbourne <pcc@...gle.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Jens Axboe <axboe@...nel.dk>, legion@...nel.org, eb@...ix.com,
        Muchun Song <songmuchun@...edance.com>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        thomascedeno@...gle.com, sashal@...nel.org, cxfcosmos@...il.com,
        linux@...musvillemoes.dk, LKML <linux-kernel@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-mm <linux-mm@...ck.org>,
        kernel-team <kernel-team@...roid.com>
Subject: Re: [PATCH v8 2/3] mm: add a field to store names for private
 anonymous memory

On 28/08/2021 23.47, Suren Baghdasaryan wrote:
> On Fri, Aug 27, 2021 at 10:52 PM Kees Cook <keescook@...omium.org> wrote:
>>
>>>> +   case PR_SET_VMA_ANON_NAME:
>>>> +           name = strndup_user((const char __user *)arg,
>>>> +                               ANON_VMA_NAME_MAX_LEN);
>>>> +
>>>> +           if (IS_ERR(name))
>>>> +                   return PTR_ERR(name);
>>>> +
>>>> +           for (pch = name; *pch != '\0'; pch++) {
>>>> +                   if (!isprint(*pch)) {
>>>> +                           kfree(name);
>>>> +                           return -EINVAL;
>>>
>>> I think isprint() is too weak a check.  For example, I would suggest
>>> forbidding the following characters: ':', ']', '[', ' '.  Perhaps

Indeed. There's also the issue that the kernel's ctype actually
implements some almost-but-not-quite latin1, so (some) chars above 0x7f
would also pass isprint() - while everybody today expects utf-8, so the
ability to put almost arbitrary sequences of chars with the high bit set
could certainly confuse some parsers. IOW, don't use isprint() at all,
just explicitly check for the byte values that we and up agreeing to
allow/forbid.

>>> isalnum() would be better?  (permit a-zA-Z0-9)  I wouldn't necessarily
>>> be opposed to some punctuation characters, but let's avoid creating
>>> confusion.  Do you happen to know which characters are actually in use
>>> today?
>>
>> There's some sense in refusing [, ], and :, but removing " " seems
>> unhelpful for reasonable descriptors. As long as weird stuff is escaped,
>> I think it's fine. Any parser can just extract with m|\[anon:(.*)\]$|
> 
> I see no issue in forbidding '[' and ']' but whitespace and ':' are
> currently used by Android. Would forbidding or escaping '[' and ']' be
> enough?

how about allowing [0x20, 0x7e] except [0x5b, 0x5d], i.e. all printable
(including space) ascii characters, except [ \ ] - the brackets as
already discussed, and backslash because then there's nobody who can get
confused about whether there's some (and then which?) escaping mechanism
in play - "\n" is simply never going to appear. Simple rules, easy to
implement, easy to explain in a man page.

>>
>> For example, just escape it here instead of refusing to take it. Something
>> like:
>>
>>         name = strndup_user((const char __user *)arg,
>>                             ANON_VMA_NAME_MAX_LEN);
>>         escaped = kasprintf(GFP_KERNEL, "%pE", name);

I would not go down that road. First, it makes it much harder to explain
the rules for what are allowed and not allowed. Second, parsers become
much more complicated. Third, does the length limit then apply to the
escaped or unescaped string?

Rasmus