On Mon, Oct 19, 2015 at 6:19 PM, Austin S HemmelgarnApologies for being unintentionally over-inclusive WRT LSM's, and also for forgetting that TOMOYO doesn't use inode labels.
<ahferroin7@xxxxxxxxx> wrote:
On 2015-10-19 11:34, Andreas Gruenbacher wrote:
On Mon, Oct 19, 2015 at 3:16 PM, Austin S HemmelgarnOK, so to clarify, this isn't 'safe' because:
<ahferroin7@xxxxxxxxx> wrote:
On 2015-10-16 13:41, Andreas Gruenbacher wrote:See here: http://www.spinics.net/lists/linux-ext4/msg49541.html
On Fri, Oct 16, 2015 at 7:31 PM, Austin S HemmelgarnOK, seeing as I wasn't particularly clear as to why I object to this in
<ahferroin7@xxxxxxxxx> wrote:
I would like to re-iterate, on both XFS and ext4, I _really_ think thisIt is unfortunately not safe to make such a file system accessible to
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,
other users, so the feature is not strictly read-only compatible.
my
other e-mail, let's try this again.
Can you please explain exactly why it isn't safe to make such a
filesystem
accessible to other users?
1. The richacls that exist on the filesystem won't be enforced.
2. Newly created files will have no ACL's set.
It is worth noting that these are also issues with any kind of access
control mechanism. Using your logic, all LSM's need to set separate
incompat feature flags in filesystems they are being used on, as should
POSIX ACLs, and for that matter so should Samba in many circumstances, and
any NFS system not using idmapping or synchronized/centralized user
databases. Now, if the SELinux (or SMACK, or TOMOYO) people had taken this
approach, then I might be inclined to not complain (at least not to you, I'd
be complaining to them about this rather poor design choice), but that is
not the case, because (I assume) they realized that all this provides is a
false sense of security.
LSMs reside above the filesystem level. Let's take SELinux as an
example. It has its own consistency check mechanism (relabeling). Fsck
could check the syntax of SELinux labels, but it couldn't do anything
sensible about corrupted labels, and syntactically correct labels also
don't mean much. A relabeling run to verify or restory the appropriate
policy would still be necessary to verify that labels are semantically
correct, and for that, the filesystem needs to be mounted in the right
place in the filesystem hierarchy.
TOMOYO and AppArmor are not based on inode labels at all.
LSMs usually also just provide an extra layer of security; when turnedUm, actually no, even without MLS (or MCS), there is no guarantee whatsoever that the system will work 'just' like before (I've actually seen systems break on any (or even in one case all) of the transitions between enforcing/permissive/off for SELinux, even assuming that relabeling is done properly).
off, the basic security mechanisms still in effect will make sure that
the system works just like before. (There are configurations like MLS
where that is not the case, but those are uncommon.)
ACLs are quite different from that. They can be checked statically byLSM's hook into the VFS code right alongside the regular permissions checks. They are intended to supplement the regular UNIX DAC based permissions. Richacls (and POSIX ACLs) also hook into the regular permissions checks, and also are intended to supplement the regular UNIX DAC based permissions. Fsck only checks the syntax of regular UNIX DAC based permissions (it doesn't verify that the listed UID/GID are actually valid in userspace, nor does it check for semantically nonsensical permissions modes like 007 or 000), and it really can't properly check anything more than that on ACL's either. Based on all of this, richacls and LSM's which mediate filesystem accesses are on exactly the same level with the exception that LSM's usually have way more functionality beyond just using ACL's to control file access, LSM's are usually MAC based while ACL's are DAC based, and the fact that ACL's are (usually) not dependent on where in the filesystem hierarchy they are found.
fsck. They are a basic security concept, and when turned off, there is
no guarantee that the system will still be safe.
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.Issue 1, as I have said before, is functionally irrelevant for anyone whoPlease spare me with all that nonsense. Compared to mount options,
actually knows what they are doing; all you need for ext* is one of the
myriad of programs for un-deleting files on such a filesystem (such as
ext4magic or extundelete, and good luck convincing them to not allow being
used when this flag is set), for BTRFS you just need the regular filesystem
administration utilities ('btrfs restore' works wonders, and that one will
_never_ honor any kind of permissions, because it's for disaster recovery),
and while I don't know of any way to do this with XFS, that is only because
I don't use XFS myself and have not had the need to provide tech support for
anyone who does. If somebody absolutely _needs_ a guarantee that the acls
will be enforced, they need to be using whole disk encryption, not just
acls, and even that can't provide such a guarantee.
As for issue 2, that can be solved by making it a read-only compatible flag,
which is what I was suggesting be done in the first place. The only
situation I can think of that this would cause an issue for is if the
filesystem was not cleanly unmounted, and the log-replay doesn't set the
ACL's, but mounting an uncleanly unmounted filesystem that has richacls on a
kernel without support should fall into one of the following 2 cases more
than 99% of the time:
1. The system crashed hard, and the regular kernel is un-bootable for some
reason, in this case you're at the point of disaster recovery, should not be
exposing _anything_ to a multi-user environment, and probably care a lot
more about being able to get the system running again than about not
accidentally creating a file with a missing ACL.
2. The filesystem was maliciously stolen in some way (either the hardware
was acquired, or more likely, someone got an image of a still mounted
filesystem), in which case all of my statements above regarding issue 1
apply.
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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature