Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1185075

Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces

Show all headers | View raw

On Wed, Jul 15, 2015 at 2:48 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> On Wed, Jul 15, 2015 at 02:46:04PM -0500, Seth Forshee wrote:
>> Capability sets attached to files must be ignored except in the
>> user namespaces where the mounter is privileged, i.e. s_user_ns
>> and its descendants. Otherwise a vector exists for gaining
>> privileges in namespaces where a user is not already privileged.
>>
>> Add a new helper function, in_user_ns(), to test whether a user
>> namespace is the same as or a descendant of another namespace.
>> Use this helper to determine whether a file's capability set
>> should be applied to the caps constructed during exec.
>>
>> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
>
> Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
>
> I think it's an ok behavior, though let's just go over the
> alternatives.
>
> It might actually be ok to simply require that the user_ns be
> equal.  If I unshare a new userns in which a different uid is
> mapped to root, I may not want file capabilities to be granted
> to tasks in that ns.  (On the other hand, I might be creating
> a new user_ns specifically to not have a uid 0 mapped into it
> at all, and only have file capabilities grant privilege)
>
> Conversely, if I unshare one user_ns with a MS_SHARED mnt_ns, mount
> an ext4fs, and then (from the parent shell) unshare another user_ns
> with the same mapping, intending it to be a "peer" to the first one
> I'd unshared and be able to use the ext4fs it mounted.  This won't
> work here.  That's probably best - the appropriate thing to do was
> to attach to the existing user_ns.  But it could end up being
> limiting in some special cases, so I'm bringing it up here.
>
> Again I think what you have here is the simplest and most sensible
> choice, so ack.
>

I think I'm missing something.  Why is this separate from mount_may_suid?

I can see why it would make sense to check s_user_ns (or maybe
s_user_ns *and* the vfsmount namespace) in mount_may_suid, but I don't
see why we need separate checks.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user  namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2015-07-15 23:50 +0200
  Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces Andy Lutomirski <luto@amacapital.net> - 2015-07-16 00:00 +0200
    Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user  namespaces Seth Forshee <seth.forshee@canonical.com> - 2015-07-16 03:20 +0200
      Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces Andy Lutomirski <luto@amacapital.net> - 2015-07-16 03:30 +0200
    Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces Andy Lutomirski <luto@amacapital.net> - 2015-07-16 03:30 +0200
      Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2015-07-17 03:00 +0200

csiph-web