Andy Whitcroft <apw@xxxxxxxxxxxxx> writes: > When checking permissions on an overlayfs inode we do not take into > account either device cgroup restrictions nor security permissions. > This allows a user to mount an overlayfs layer over a restricted device > directory and by pass those permissions to open otherwise restricted > files. > > Use devcgroup_inode_permission() and security_inode_permission() against > the underlying inodes when calculating ovl_permission(). Andy, Thanks for the patch. __devcgroup_inode_permission() and security_inode_permission() are not exported to modules, so this will not work if overlayfs is a module. We could export those but I think a better solution is to split out the part of inode_permission() that doesn't check for a read-only fs and export that. Thanks, Miklos > > Signed-off-by: Andy Whitcroft <apw@xxxxxxxxxxxxx> > --- > fs/overlayfs/inode.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > Not sure whether you saw this the first time round. This was shown > up in testing with containers, specifically with device cgroups. > It seems we should be re-checking here else users can simply > bypass the containers device permissions by mounting an overlayfs > fs over them. > > diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c > index ba1a777..1145a76 100644 > --- a/fs/overlayfs/inode.c > +++ b/fs/overlayfs/inode.c > @@ -10,6 +10,8 @@ > #include <linux/fs.h> > #include <linux/slab.h> > #include <linux/xattr.h> > +#include <linux/device_cgroup.h> > +#include <linux/security.h> > #include "overlayfs.h" > > int ovl_setattr(struct dentry *dentry, struct iattr *attr) > @@ -118,6 +120,11 @@ int ovl_permission(struct inode *inode, int mask) > err = realinode->i_op->permission(realinode, mask); > else > err = generic_permission(realinode, mask); > + > + if (!err) > + err = devcgroup_inode_permission(realinode, mask); > + if (!err) > + err = security_inode_permission(realinode, mask); > out_dput: > dput(alias); > return err; -- 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
