On Mon, Oct 19, 2015 at 8:45 PM, Austin S HemmelgarnExcept 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.
<ahferroin7@xxxxxxxxx> 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 isYes, 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.
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.
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.
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.
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.
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 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.
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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature