Security Vulnerability Report: Cross-filesystem ACL Permissions Issue in Different File Systems (EXT4, XFS, NTFS, etc.)

Security Vulnerability Report: Cross-filesystem ACL Permissions Issue in Different File Systems (EXT4, XFS, NTFS, etc.)

[李溢林]

[-- Attachment #1.1: Type: text/plain, Size: 2612 bytes --]

Dear Linux kernel security team,
I am writing to report a security vulnerability related to cross-filesystem permissions management that I have discovered. This issue appears to impact filesystems like EXT4 and XFS, and it could potentially lead to unauthorized access of sensitive data during the migration of files between different filesystems with varying permission models.
The vulnerability arises when a file with Access Control List (ACL) restrictions, created in a file system that supports ACL (e.g., EXT4 or XFS), is moved or copied to a file system that does not support ACL (e.g., FAT32 or NTFS). During this migration, the ACLs are lost, and the file's permissions fall back to default settings on the target file system, which may allow unauthorized users to access the file.


In certain scenarios, this could lead to privilege escalation or unauthorized access to sensitive files. The issue is especially critical in shared directories or network file systems (e.g., NFS), where users with limited permissions could bypass ACL protections by moving files to other file systems.



The vulnerability occurs when a file with POSIX ACLs (set on EXT4 or XFS) is moved or copied to a file system that uses Windows ACLs (such as NTFS). In this case, the POSIX ACLs are not preserved during the migration, and the file’s permissions are reset to default or more lenient permissions on the target file system. As a result, the file may become accessible to unauthorized users or attackers, bypassing the original ACL restrictions.



Here is a summary of how to reproduce the issue:


1. On an EXT4 or XFS file system, create a file with a specific POSIX ACL that denies access to certain users (e.g., user2).
2. Attempt to move or copy this file to an NTFS file system, which uses Windows ACLs.
3. Upon migration, the POSIX ACL is discarded, and the file’s permissions are reset to the default permissions of the NTFS file system (usually wide-open access).
4. The file can now be accessed by users who were previously restricted under POSIX ACL, allowing unauthorized access.


This issue is critical when files are transferred between file systems with incompatible ACL implementations, particularly in multi-user or shared environments. I have tested this behavior on multiple systems, and it is clear that moving files between file systems with different ACL models leads to unintended permission changes. 

Thank you for your attention to this matter. I look forward to your feedback and any further steps in addressing this issue.



Best regards,
Yilin Li
Shandong University 













[-- Attachment #1.2: Type: text/html, Size: 3256 bytes --]

[-- Attachment #2: figure.jpg --]
[-- Type: image/jpeg, Size: 225810 bytes --]

Re: Security Vulnerability Report: Cross-filesystem ACL Permissions Issue in Different File Systems (EXT4, XFS, NTFS, etc.)

[Theodore Ts'o]

On Thu, Jan 23, 2025 at 04:54:30PM +0800, 李溢林 wrote:
> I am writing to report a security vulnerability related to
> cross-filesystem permissions management that I have discovered. This
> issue appears to impact filesystems like EXT4 and XFS, and it could
> potentially lead to unauthorized access of sensitive data during the
> migration of files between different filesystems with varying
> permission models.
>
> The vulnerability arises when a file with Access Control List (ACL)
> restrictions, created in a file system that supports ACL (e.g., EXT4
> or XFS), is moved or copied to a file system that does not support
> ACL (e.g., FAT32 or NTFS). During this migration, the ACLs are lost,
> and the file's permissions fall back to default settings on the
> target file system, which may allow unauthorized users to access the
> file.

What is your proposal for how to address this?  I'm not really sure
I'd call it a "vulnerability", per se.  If the user is relying on a
particular ACL to deny access using negative access, and they copy the
file somewhere that doesn't support Posix ACL's, this is the natural
and expected effect.

There are plenty of ways this could happen beyond the one that you've
describe.  For example, they could copy the file to a file system that
doesn't support ACL's at all (such as say a FAT file system).  They
could create a tar file.  They could use rsync or scp to copy the
directory hierarcy, etc.

Further, I'll note that NFS (sometimes fondly referred to by security
folks as "No File Security") relies on the client asserting the user
id accessing the file.  (Yes, in theory NFS could use Kerberos or
GSSAPI to provide user-level authentication, but in practice, this is
**extremely** rare.)  Furthermore, the system administration policies
of the client might very well be different from the server.  For
example, users might have physical access to the client, making it
trivially possible to gain root, where as the server might be in a
locked machine room.

For example, consider how we used Kerberos authentcation, NFS, and the
fact that users could trvially get root on their local clients[1] at
MIT Project Atenna back in the late 1980's.

[1] https://minnie.tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/thread/QB6D2L2RGO5C3BYT45RSEXKLICQYGOSF/#RYYRCWE247SEU7TGN7IPATYK3GZHGX36


I'll also note that in general, the scenario assumes that files are
accessile via local file access as well as remotely over some kind of
remote file accesss (e.g., CIFS or NFS).  Don't do that.  If you are
trying to supply access to legacy Windows machines using CIFS, then
access the files from Linux using CIFS as well, and then rely solely
on the Windows ACL model.  Otherwise, even if the files aren't getting
copied, the access checks when the files are access locally are
different from when they are accessed via some kind of remote access
protocol, whether it's a remote file system like NFS, or something
like WEBDAV.


> This issue is critical when files are transferred between file
> systems with incompatible ACL implementations, particularly in
> multi-user or shared environments. I have tested this behavior on
> multiple systems, and it is clear that moving files between file
> systems with different ACL models leads to unintended permission
> changes.

I the user is copying it from a file hiearchy using Posix ACL, to a
different file system hierarchy, then how is that different from the
"security vulnerability" where the user copies it to a USB thumb
drive, and then takes the USB thumb drive out, and hands it to a spy?
Oh, noes!!!

Fundamentally, if you don't trust the user (either because they might
be malicious, or because they are incompetent), Discretionary Access
Controls (DAC) are not going to help you.  This is why Mandatory
Access Controls (MAC) were invented.  Of course, MAC's are extremely
painful to use, and so in practice almost no one tries to use MAC
today.  Military organizations might use it if they have unlimited
budget, but even there, it's often easier to have separate systems for
unclassified informations and for classified information, and you
control physical access via armed guards and the signs saying "Deadly
Force is Authorized".  :-)

Cheers,

					- Ted