Re: [PATCH v11 21/48] ext4: Add richacl feature flag

Austin S Hemmelgarn
2015-10-16T18:28:15Z

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

On 2015-10-16 13:41, Andreas Gruenbacher wrote:
> On Fri, Oct 16, 2015 at 7:31 PM, Austin S Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>> I would like to re-iterate, on both XFS and ext4, I _really_ think this
>> should be a ro_compat flag, and not an incompat one. If a person has the
>> ability to mount the FS (even if it's a read-only mount), then they by
>> definition have read access to the file or partition that the filesystem is
>> contained in, which means that any ACL's stored on the filesystem are
>> functionally irrelevant,
>
> It is unfortunately not safe to make such a file system accessible to
> other users, so the feature is not strictly read-only compatible.
If it's not safe WRT data integrity, then the design needs to be
reworked, as that directly implies that isn't safe for even every day
usage on a writable filesystem.

If it's not safe WRT the ACL's being honored, then that really isn't
something we should be worrying about. POSIX ACL's have this issue, as
does mounting a filesystem on any system with a different
/etc/{passwd,shadow,group,gshadow} than the one that wrote the
permissions to the FS in the first place, and as such this is the type
of thing any sensible system administrator will already expect to be
dangerous, which means in turn that they will only do it if there is no
other choice.

Trying to rely on making this an incompat feature to 'enforce' the ACL's
is inherently flawed for two very specific reasons:
1. If the person theoretically trying to attack the system has write
access to the disk, they can flip the feature bit and get access anyway
(seriously, this takes maybe ten minutes of looking at the source code,
some simple math and a hex editor).
2. If the disk is read-only (or even if it's writable), they can just
forgo mounting the filesystem entirely and use any of a number of
existing tools to pull the data directly off of the disk.

As I said in a previous discussion about this, the three most likely
reasons for someone mounting a filesystem with this feature on a kernel
that doesn't support it are:
1. They've booted into a recovery environment (eg SystemRescueCD) to
attempt to recover data from the system itself (this usage implies
access to the hardware, and therefore the ACL's are inherently useless
for protecting the data anyway).
2. They've pulled the disk and hooked it up to a different system to
recover data from it (again, this implies access to the hardware, and
ACL's are inherently useless for protecting from this).
3. They're trying to bisect a kernel bug introduced at around the same
time that richacls went in (which means again they have hardware access
and ACL's are useless).
All that making this an incompat feature will do is make things harder
for these legitimate use cases, for any competent attacker it will only
be a minor inconvenience.

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]