linux-kernel - Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs

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]

Message-ID: <8447a726-c45d-8ebb-2a74-a4d759631e64@linux.vnet.ibm.com>
Date:   Wed, 9 Nov 2022 15:10:37 -0500
From:   Nayna <nayna@...ux.vnet.ibm.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Nayna Jain <nayna@...ux.ibm.com>
Cc:     linuxppc-dev@...ts.ozlabs.org, linux-fsdevel@...r.kernel.org,
        linux-efi@...r.kernel.org,
        linux-security-module <linux-security-module@...r.kernel.org>,
        linux-kernel@...r.kernel.org,
        Michael Ellerman <mpe@...erman.id.au>, npiggin@...il.com,
        christophe.leroy@...roup.eu, Dov Murik <dovmurik@...ux.ibm.com>,
        George Wilson <gcwilson@...ux.ibm.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Russell Currey <ruscur@...sell.cc>,
        Andrew Donnellan <ajd@...ux.ibm.com>,
        Stefan Berger <stefanb@...ux.ibm.com>
Subject: Re: [PATCH 2/4] fs: define a firmware security filesystem named
 fwsecurityfs

On 11/9/22 08:46, Greg Kroah-Hartman wrote:
> On Sun, Nov 06, 2022 at 04:07:42PM -0500, Nayna Jain wrote:
>> securityfs is meant for Linux security subsystems to expose policies/logs
>> or any other information. However, there are various firmware security
>> features which expose their variables for user management via the kernel.
>> There is currently no single place to expose these variables. Different
>> platforms use sysfs/platform specific filesystem(efivarfs)/securityfs
>> interface as they find it appropriate. Thus, there is a gap in kernel
>> interfaces to expose variables for security features.
>>
>> Define a firmware security filesystem (fwsecurityfs) to be used by
>> security features enabled by the firmware. These variables are platform
>> specific. This filesystem provides platforms a way to implement their
>>   own underlying semantics by defining own inode and file operations.
>>
>> Similar to securityfs, the firmware security filesystem is recommended
>> to be exposed on a well known mount point /sys/firmware/security.
>> Platforms can define their own directory or file structure under this path.
>>
>> Example:
>>
>> # mount -t fwsecurityfs fwsecurityfs /sys/firmware/security
> Why not juset use securityfs in /sys/security/firmware/ instead?  Then
> you don't have to create a new filesystem and convince userspace to
> mount it in a specific location?

 From man 5 sysfs page:

/sys/firmware: This subdirectory contains interfaces for viewing and 
manipulating firmware-specific objects and attributes.

/sys/kernel: This subdirectory contains various files and subdirectories 
that provide information about the running kernel.

The security variables which are being exposed via fwsecurityfs are 
managed by firmware, stored in firmware managed space and also often 
consumed by firmware for enabling various security features.

 From git commit b67dbf9d4c1987c370fd18fdc4cf9d8aaea604c2, the purpose 
of securityfs(/sys/kernel/security) is to provide a common place for all 
kernel LSMs. The idea of
fwsecurityfs(/sys/firmware/security) is to similarly provide a common 
place for all firmware security objects.

/sys/firmware already exists. The patch now defines a new /security 
directory in it for firmware security features. Using 
/sys/kernel/security would mean scattering firmware objects in multiple 
places and confusing the purpose of /sys/kernel and /sys/firmware.

Even though fwsecurityfs code is based on securityfs, since the two 
filesystems expose different types of objects and have different 
requirements, there are distinctions:

1. fwsecurityfs lets users create files in userspace, securityfs only 
allows kernel subsystems to create files.

2. firmware and kernel objects may have different requirements. For 
example, consideration of namespacing. As per my understanding, 
namespacing is applied to kernel resources and not firmware resources. 
That's why it makes sense to add support for namespacing in securityfs, 
but we concluded that fwsecurityfs currently doesn't need it. Another 
but similar example of it is: TPM space, which is exposed from hardware. 
For containers, the TPM would be made as virtual/software TPM. Similarly 
for firmware space for containers, it would have to be something 
virtualized/software version of it.

3. firmware objects are persistent and read at boot time by interaction 
with firmware, unlike kernel objects which are not persistent.

For a more detailed explanation refer to the LSS-NA 2022 "PowerVM 
Platform Keystore - Securing Linux Credentials Locally" talk and 
slides[1]. The link to previously posted RFC version is [2].

[1] 
https://static.sched.com/hosted_files/lssna2022/25/NaynaJain_PowerVM_PlatformKeyStore_SecuringLinuxCredentialsLocally.pdf
[2] https://lore.kernel.org/linuxppc-dev/YrQqPhi4+jHZ1WJc@kroah.com/

Thanks & Regards,

      - Nayna

>
> thanks,
>
> greg k-h