Re: [PATCH v16 3/4] overlayfs: override_creds=off option bypass creator_cred
From: Amir Goldstein <amir73il@gmail.com>
Date: 2020-10-19 15:17:37
Also in:
linux-doc, linux-unionfs, lkml
On Mon, Oct 19, 2020 at 2:53 PM Mark Salyzyn [off-list ref] wrote:
By default, all access to the upper, lower and work directories is the recorded mounter's MAC and DAC credentials. The incoming accesses are checked against the caller's credentials. If the principles of least privilege are applied, the mounter's credentials might not overlap the credentials of the caller's when accessing the overlayfs filesystem. For example, a file that a lower DAC privileged caller can execute, is MAC denied to the generally higher DAC privileged mounter, to prevent an attack vector. We add the option to turn off override_creds in the mount options; all subsequent operations after mount on the filesystem will be only the caller's credentials. The module boolean parameter and mount option override_creds is also added as a presence check for this "feature", existence of /sys/module/overlay/parameters/override_creds. It was not always this way. Circa 4.6 there was no recorded mounter's credentials, instead privileged access to upper or work directories were temporarily increased to perform the operations. The MAC (selinux) policies were caller's in all cases. override_creds=off partially returns us to this older access model minus the insecure temporary credential increases. This is to permit use in a system with non-overlapping security models for each executable including the agent that mounts the overlayfs filesystem. In Android this is the case since init, which performs the mount operations, has a minimal MAC set of privileges to reduce any attack surface, and services that use the content have a different set of MAC privileges (eg: read, for vendor labelled configuration, execute for vendor libraries and modules). The caveats are not a problem in the Android usage model, however they should be fixed for completeness and for general use in time. Signed-off-by: Mark Salyzyn <redacted> To: linux-fsdevel@vger.kernel.org To: linux-unionfs@vger.kernel.org Cc: Miklos Szeredi <miklos@szeredi.hu> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Eric W. Biederman <redacted> Cc: Amir Goldstein <amir73il@gmail.com> Cc: Randy Dunlap <redacted> Cc: Stephen Smalley <redacted> Cc: John Stultz <redacted> Cc: linux-security-module@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: kernel-team@android.com
Please CC [off-list ref] for overlayfs patches
quoted hunk ↗ jump to hunk
v16 - Rebase, cover a few more new ovl_revert_creds callpoints. v15 - Rebase v14: - fix an issue in ovl_create_or_link which leaks credentials. v12 + v13 - Rebase v11: - add sb argument to ovl_revert_creds to match future work in progress in other commiter's hands. v10: - Rebase (and expand because of increased revert_cred usage) v9: - Add to the caveats v8: - drop pr_warn message after straw poll to remove it. - added a use case in the commit message v7: - change name of internal parameter to ovl_override_creds_def - report override_creds only if different than default v6: - Drop CONFIG_OVERLAY_FS_OVERRIDE_CREDS. - Do better with the documentation. - pr_warn message adjusted to report consequences. v5: - beefed up the caveats in the Documentation - Is dependent on "overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh" "overlayfs: check CAP_MKNOD before issuing vfs_whiteout" - Added prwarn when override_creds=off v4: - spelling and grammar errors in text v3: - Change name from caller_credentials / creator_credentials to the boolean override_creds. - Changed from creator to mounter credentials. - Updated and fortified the documentation. - Added CONFIG_OVERLAY_FS_OVERRIDE_CREDS v2: - Forward port changed attr to stat, resulting in a build error. - altered commit message. --- Documentation/filesystems/overlayfs.rst | 23 +++++++++++++++++++++++ fs/overlayfs/copy_up.c | 2 +- fs/overlayfs/dir.c | 17 ++++++++++------- fs/overlayfs/file.c | 24 ++++++++++++------------ fs/overlayfs/inode.c | 18 +++++++++--------- fs/overlayfs/namei.c | 6 +++--- fs/overlayfs/overlayfs.h | 1 + fs/overlayfs/ovl_entry.h | 1 + fs/overlayfs/readdir.c | 8 ++++---- fs/overlayfs/super.c | 22 +++++++++++++++++++++- fs/overlayfs/util.c | 13 +++++++++++-- 11 files changed, 96 insertions(+), 39 deletions(-)diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst index 580ab9a0fe31..18ac7d35c145 100644 --- a/Documentation/filesystems/overlayfs.rst +++ b/Documentation/filesystems/overlayfs.rst@@ -137,6 +137,29 @@ Only the lists of names from directories are merged. Other content such as metadata and extended attributes are reported for the upper directory only. These attributes of the lower directory are hidden. +credentials +----------- + +By default, all access to the upper, lower and work directories is the +recorded mounter's MAC and DAC credentials. The incoming accesses are +checked against the caller's credentials. + +In the case where caller MAC or DAC credentials do not overlap, a +use case available in older versions of the driver, the +override_creds mount flag can be turned off and help when the use +pattern has caller with legitimate credentials where the mounter +does not. Several unintended side effects will occur though. The +caller without certain key capabilities or lower privilege will not +always be able to delete files or directories, create nodes, or +search some restricted directories. The ability to search and read +a directory entry is spotty as a result of the cache mechanism not +retesting the credentials because of the assumption, a privileged +caller can fill cache, then a lower privilege can read the directory +cache. The uneven security model where cache, upperdir and workdir +are opened at privilege, but accessed without creating a form of +privilege escalation, should only be used with strict understanding +of the side effects and of the security policies. +
Since your earlier versions, overlayfs.rst grew the section 'Permission model'. Please work your documentation into that section or at least add it near the new section and make sure that the content of the two sections do not contradicts each other. Thanks, Amir.