On Thu, Dec 22, 2016 at 09:58:42AM +0100, Mickaël Salaün wrote: > Of course a read-only mount point can do the trick (except for anonymous > inodes). However, a security policy (e.g. for SELinux) should not (and > can't always) rely on mount options. For example, a security policy can > come from a distro but they may not want to tie mount options with this > policy. We may also not want a sandbox to being able to change mount > options (even with user namespaces). > > Being able to write (meta-)data, whereas a security policy said that > it's not allowed, seems like a flaw in this policy. Moreover, modifying > access time is an easy way to create cover-channels without any LSM > being able to notice it. A security policy must not mess with the readonly state of a file system or mount, period. You're overstepping your boundaries. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
