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

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: <CAHc6FU4jcatmY+A39oQb-2x9Gs8WFVsXOD_9eBV=_fgNzZx3Xg@mail.gmail.com>
Date:	Mon, 19 Oct 2015 22:20:43 +0200
From:	Andreas Gruenbacher <agruenba@...hat.com>
To:	Austin S Hemmelgarn <ahferroin7@...il.com>
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	"Theodore Ts'o" <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Jeff Layton <jlayton@...chiereds.net>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	Anna Schumaker <anna.schumaker@...app.com>,
	Dave Chinner <david@...morbit.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>, xfs@....sgi.com,
	LKML <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	linux-cifs@...r.kernel.org, Linux API <linux-api@...r.kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: [PATCH v11 21/48] ext4: Add richacl feature flag

On Mon, Oct 19, 2015 at 8:45 PM, Austin S Hemmelgarn
<ahferroin7@...il.com> wrote:
> On 2015-10-19 13:33, Andreas Gruenbacher wrote:
>> Please spare me with all that nonsense. Compared to mount options,
>> filesystem feature flags in this case simplify things (you don't have
>> to specify whether a filesystem contains POSIX ACLs or richacls), and
>> they prevent administrator errors: when a filesystem mounts, it is
>> safe to use; when it doesn't, it is not. That's all there is to it.
>
> You're ignoring what I'm actually saying. I've said absolutely nothing
> about needing to use mount options at all, and I'm not arguing against using
> filesystem feature flags, I'm arguing for using them sensibly in a way that
> does not present a false sense of security.

We could be on a multi-user system, and the user mounting the
filesystem may not be the only user on the system. When a filesystem
can be mounted read-only, it should be safe to use read-only. It is
not safe in general to use such a filesystem read-only, so an
incompatible feature flag which prevents such unsafe mounting is more
approporiate than a read-only incompatible feature flag.

Mounting a filesystem read-only doesn't mean that the filesystem is
being recovered, it is perfectly legal to mount a filesystem read-only
for other reasons. I don't want to give people using read-only
filesystems the false sense that everything is okay.

> Making it an incompatible flag will likely cause headaches for some
> legitimate users,

Indeed. It will also make it less likely for users to accidentally
shoot themselves in the foot. If someone knows better, they can clear
the feature flag.

When recovering a broken system that contains richacl filesystems, you
really want to have richacl support in the rescue system as well.
Otherwise, you won't be able to fsck those filesystems.

> and at most delay competent hackers by a few seconds to a
> few minutes, and script kiddies by a few hours, and is really no better than
> security by obscurity (and from a purely logistical standpoint, that's _all_
> it is) in that it actively tries to hide the fact that someone having read
> access to the storage the filesystem is on can bypass the ACL's.
>
> To reiterate, if someone can call mount() on a filesystem, and mount() does
> not return -EPERM, then even if mount() returns a different error, they
> still have the ability to completely bypass all permissions and ACL's in
> that filesystem, because they have the ability to read the entire filesystem
> directly.
>
> The _only_ way to properly protect against people bypassing the ACL's is to
> use full disk encryption and lock down root access on the system, and even
> that can't completely prevent it from happening.

That's all completely beside the point. I'm not talking about
preventing attacks at all, just basic administrative workflows.

Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/