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

From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: linux-cifs@vger.kernel.org,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Theodore Ts'o <tytso@mit.edu>,
	Linux API <linux-api@vger.kernel.org>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	LKML <linux-kernel@vger.kernel.org>,
	xfs@oss.sgi.com, "J. Bruce Fields" <bfields@fieldses.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Jeff Layton <jlayton@poochiereds.net>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	Anna Schumaker <anna.schumaker@netapp.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: [PATCH v11 21/48] ext4: Add richacl feature flag
Date: Tue, 20 Oct 2015 08:33:54 -0400	[thread overview]
Message-ID: <562634B2.30209@gmail.com> (raw)
In-Reply-To: <CAHc6FU4jcatmY+A39oQb-2x9Gs8WFVsXOD_9eBV=_fgNzZx3Xg@mail.gmail.com>


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

On 2015-10-19 16:20, Andreas Gruenbacher wrote:
> On Mon, Oct 19, 2015 at 8:45 PM, Austin S Hemmelgarn
> <ahferroin7@gmail.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.
Except that mounting a filesystem that wasn't created on the system 
mounting it always has that exact same risk, because (AFAIK) all 
Linux/BSD/Other UNIX filesystems store GID's and UID's as numbers, not 
names.  Perfect example of this, take a minimal install of some Linux 
distribution, install a couple of packages that add new UID's, and mount 
the root filesystem on a completely different distribution (say mount a 
Debian root filesystem on a Gentoo box), any of the new UID's from the 
first system will almost certainly not map to the same user on the 
second system (in fact, you can also do this with two Gentoo systems 
where the packages were installed in different orders).  This is a 
really basic security risk that any seasoned sysadmin should know, and 
most new ones find out about rather quickly.

Also, based on established context of _every_ other feature with an 
incompat feature flag in both ext4 and XFS, 'safe' means that you can 
get the correct file contents off of the filesystem,and don't run the 
risk of crashing the system, not that you have no risk of compromising 
security.
> 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.
Yes, and this is why any sane filesystem will spit a warning out through 
dmesg when a mount is forced read-only because of incompatible features. 
  If someone is actively mounting such a filesystem read-only (that is, 
they've specified 'ro' in the mount options), then it's relatively safe 
for the kernel to assume they are doing so for some very specific reason 
and/or already know about the data safety implications.
>
>> 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.
Except there will be a lot of people who think they know better but 
really don't.  Such people will do this anyway, and by modifying the 
filesystem run a bigger risk of shooting themselves in the foot (because 
they'll almost certainly mount the filesystem read-write, and then end 
up turning on richacls again).  You're not removing the gun, you're just 
hiding a potentially bigger one somewhere else.

It's a separate issue entirely however whether or not you absolutely 
need to know that the richacls have the correct syntax in a recovery 
situation.  Fsck doesn't parse SELinux labels, (AFAIK) doesn't parse 
filecaps attributes (bad filecaps syntax will only make things have 
fewer privileges, but it will cause user visible brokenness), (again, 
AFAIK) doesn't validate POSIX ACL's, and absolutely doesn't check IMA or 
EVM hashes.  IMA and EVM hashes being wrong _will_ cause almost any 
system actually using them they way they are intended to fail to boot, 
and incorrect SELinux labeling will make many systems not boot 
correctly, and both situations are much worse for a significant majority 
of users than a (security leak due to a bad ACL.
>
> 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.
While it's something that 'should' be the case, there are probably quite 
a few people who will not realize this until they're already in a 
situation that they need to recover data.  On top of that some people 
will likely assume that they just need richacl support in userspace for 
their recovery environment.
>
>> 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.
While that may be the case, there will be people who assume that because 
it's an incompat feature, their ACL's will _always_ be enforced.  Such 
people should admittedly not be allowed to run systems with any real 
world security requirements, but that mentality is something that still 
needs to be considered, and this is arguably making it easier for them 
to shoot themselves in the foot.


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

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs