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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/8] mount ownership and unprivileged mount syscall (v4)
> > 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. > 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. In fact the latest patches don't even support these "legacy" user mounts too well: setting the owner of a mount gives not only umount privilege, but the ability to submount. This is not necessarily a good thing for these kinds of user mounts. 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. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/8] mount ownership and unprivileged mount syscall (v4)
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. 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. In fact the latest patches don't even support these legacy user mounts too well: setting the owner of a mount gives not only umount privilege, but the ability to submount. This is not necessarily a good thing for these kinds of user mounts. 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. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/8] mount ownership and unprivileged mount syscall (v4)
Karel Zak <[EMAIL PROTECTED]> writes: > On Fri, Apr 20, 2007 at 12:25:32PM +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). > > It means the kernel based solution is not fully compatible ;-( Why noexec? Either it was a silly or arbitrary decision, or our kernel design may be incomplete. Now I can see not wanting to support executables if you are locking down a system. The classic don't execute a program from a CD just because the CD was stuck in the drive problem. So I can see how executing code from an untrusted source could prevent exploitation of other problems, and we certainly don't want to do it automatically. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/8] mount ownership and unprivileged mount syscall (v4)
On Fri, Apr 20, 2007 at 12:25:32PM +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). It means the kernel based solution is not fully compatible ;-( Karel -- Karel Zak <[EMAIL PROTECTED]> Red Hat Czech s.r.o. Purkynova 99/71, 612 45 Brno, Czech Republic Reg.id: CZ27690016 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/8] mount ownership and unprivileged mount syscall (v4)
On Fri, Apr 20, 2007 at 12:25:32PM +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). It means the kernel based solution is not fully compatible ;-( Karel -- Karel Zak [EMAIL PROTECTED] Red Hat Czech s.r.o. Purkynova 99/71, 612 45 Brno, Czech Republic Reg.id: CZ27690016 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/8] mount ownership and unprivileged mount syscall (v4)
Karel Zak [EMAIL PROTECTED] writes: On Fri, Apr 20, 2007 at 12:25:32PM +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). It means the kernel based solution is not fully compatible ;-( Why noexec? Either it was a silly or arbitrary decision, or our kernel design may be incomplete. Now I can see not wanting to support executables if you are locking down a system. The classic don't execute a program from a CD just because the CD was stuck in the drive problem. So I can see how executing code from an untrusted source could prevent exploitation of other problems, and we certainly don't want to do it automatically. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
