[Devel] Re: [patch 0/8] mount ownership and unprivileged mount syscall (v4)
On Wed, Apr 25, 2007 at 09:18:28AM +0200, Miklos Szeredi wrote: The following extra security measures are taken for unprivileged mounts: - usermounts are limited by a sysctl tunable - force nosuid,nodev mount options on the created mount The original userspace user= solution also implies the noexec option by default (you can override the default by exec option). Unlike nosuid and nodev, I don't think noexec has real security benefits. Yes. I agree. It means the kernel based solution is not fully compatible ;-( Oh, I don't think that matters. For traditional /etc/fstab based user mounts, mount(8) will have to remain suid-root, the kernel can't replace the fstab check. Ok, it makes sense. You're right that for the mount(8) is more important the fstab check. Please, prepare a mount(8) patch -- with the patch it will be more clear. We could add a new nosubmount or similar flag, to prevent submounting, but that again would go against the simplicity of the current approach, so I'm not sure it's worth it. The nosubmount is probably good idea. The patches seem much better in v4. I'm fun for the feature in the kernel (and also for every change that makes mtab more and more obsolete :-). Karel Miklos - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Karel Zak [EMAIL PROTECTED] Red Hat Czech s.r.o. Purkynova 99/71, 612 45 Brno, Czech Republic Reg.id: CZ27690016 ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [patch 0/8] mount ownership and unprivileged mount syscall (v4)
Quoting Miklos Szeredi ([EMAIL PROTECTED]): This patchset has now been bared to the lowest common denominator that everybody can agree on. Or at least there weren't any objections to this proposal. Andrew, please consider it for -mm. Thanks, Miklos v3 - v4: - simplify interface as much as possible, now only a single option (user=UID) is used to control everything - no longer allow/deny mounting based on file/directory permissions, that approach does not always make sense This patchset adds support for keeping mount ownership information in the kernel, and allow unprivileged mount(2) and umount(2) in certain cases. The mount owner has the following privileges: - unmount the owned mount - create a submount under the owned mount The sysadmin can set the owner explicitly on mount and remount. When an unprivileged user creates a mount, then the owner is automatically set to the user. The following use cases are envisioned: 1) Private namespace, with selected mounts owned by user. E.g. /home/$USER is a good candidate for allowing unpriv mounts and unmounts within. 2) Private namespace, with all mounts owned by user and having the nosuid flag. User can mount and umount anywhere within the namespace, but suid programs will not work. 3) Global namespace, with a designated directory, which is a mount owned by the user. E.g. /mnt/users/$USER is set up so that it is bind mounted onto itself, and set to be owned by $USER. The user can add/remove mounts only under this directory. The following extra security measures are taken for unprivileged mounts: - usermounts are limited by a sysctl tunable - force nosuid,nodev mount options on the created mount Very nice. I like these semantics. I'll try to rework my laptop in the next few days to use this patchset as a test. thanks, -serge ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [patch 0/8] mount ownership and unprivileged mount syscall (v4)
Serge E. Hallyn [EMAIL PROTECTED] writes: Quoting Miklos Szeredi ([EMAIL PROTECTED]): This patchset has now been bared to the lowest common denominator that everybody can agree on. Or at least there weren't any objections to this proposal. Andrew, please consider it for -mm. Thanks, Miklos v3 - v4: - simplify interface as much as possible, now only a single option (user=UID) is used to control everything - no longer allow/deny mounting based on file/directory permissions, that approach does not always make sense This patchset adds support for keeping mount ownership information in the kernel, and allow unprivileged mount(2) and umount(2) in certain cases. The mount owner has the following privileges: - unmount the owned mount - create a submount under the owned mount The sysadmin can set the owner explicitly on mount and remount. When an unprivileged user creates a mount, then the owner is automatically set to the user. The following use cases are envisioned: 1) Private namespace, with selected mounts owned by user. E.g. /home/$USER is a good candidate for allowing unpriv mounts and unmounts within. 2) Private namespace, with all mounts owned by user and having the nosuid flag. User can mount and umount anywhere within the namespace, but suid programs will not work. 3) Global namespace, with a designated directory, which is a mount owned by the user. E.g. /mnt/users/$USER is set up so that it is bind mounted onto itself, and set to be owned by $USER. The user can add/remove mounts only under this directory. The following extra security measures are taken for unprivileged mounts: - usermounts are limited by a sysctl tunable - force nosuid,nodev mount options on the created mount Very nice. I like these semantics. I'll try to rework my laptop in the next few days to use this patchset as a test. Agreed. It appears the approach of adding owner ship information to mount points and using that to control what may happen with them in regards to mount/unmount is the only workable approach in the unix environment. Now to dig into the details and ensure that they are correct. Eric ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
