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] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 21 Apr 2022 08:26:10 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Peter Gonda <pgonda@...gle.com>
Cc:     Jacky Li <jackyli@...gle.com>,
        Brijesh Singh <brijesh.singh@....com>,
        John Allen <john.allen@....com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Marc Orr <marcorr@...gle.com>, Alper Gun <alpergun@...gle.com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] crypto: ccp - Fix the INIT_EX data file open failure

On 4/15/22 11:20, Peter Gonda wrote:
> On Fri, Apr 15, 2022 at 7:49 AM Tom Lendacky <thomas.lendacky@....com> wrote:
>>
>> On 4/14/22 11:23, Jacky Li wrote:
>>> There are 2 common cases when INIT_EX data file might not be
>>> opened successfully and fail the sev initialization:
>>>
>>> 1. In user namespaces, normal user tasks (e.g. VMM) can change their
>>>      current->fs->root to point to arbitrary directories. While
>>>      init_ex_path is provided as a module param related to root file
>>>      system. Solution: use the root directory of init_task to avoid
>>>      accessing the wrong file.
>>>
>>> 2. Normal user tasks (e.g. VMM) don't have the privilege to access
>>>      the INIT_EX data file. Solution: open the file as root and
>>>      restore permissions immediately.
>>>
>>> Fixes: 3d725965f836 ("crypto: ccp - Add SEV_INIT_EX support")
>>> Signed-off-by: Jacky Li <jackyli@...gle.com>
>>> Reviewed-by: Peter Gonda <pgonda@...gle.com>
>>
>> Looks good, just a quick question. Should there be any type of access
>> checks before switching credentials? Should we check access to /dev/sev or
>> such? Or is the capability to load the module enough?
> 
> I thought this was fine because regardless of if an admin sets
> psp_init_on_probe=true or false, their intention is that people who
> have rw access to /dev/sev can use the commands which require the PSP
> to be init. In the case of psp_init_on_probe=false only rw users can
> cause the file to be created. The case of psp_init_on_probe=true seems
> a little less clear to me but if a user can modprobe ccp that seems
> like sufficient privilege to create the file. What do you think, Tom?

Sorry, lost this in my Inbox...  That seems reasonable to me, let me add 
my ack to the first email.

Thanks,
Tom

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ