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

Groups > linux.kernel > #1185033 > unrolled thread

Re: [PATCH 0/7] Initial support for user namespace owned mounts

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/7] Initial support for user namespace owned mounts Casey Schaufler <casey@schaufler-ca.com> - 2015-07-15 22:40 +0200
    Re: [PATCH 0/7] Initial support for user namespace owned mounts ebiederm@xmission.com (Eric W. Biederman) - 2015-07-15 23:20 +0200
      Re: [PATCH 0/7] Initial support for user namespace owned mounts Seth Forshee <seth.forshee@canonical.com> - 2015-07-15 23:50 +0200
        Re: [PATCH 0/7] Initial support for user namespace owned mounts Andy Lutomirski <luto@amacapital.net> - 2015-07-16 03:10 +0200
          Re: [PATCH 0/7] Initial support for user namespace owned mounts ebiederm@xmission.com (Eric W. Biederman) - 2015-07-16 04:30 +0200
      Re: [PATCH 0/7] Initial support for user namespace owned mounts Andy Lutomirski <luto@amacapital.net> - 2015-07-16 03:10 +0200
        Re: [PATCH 0/7] Initial support for user namespace owned mounts Casey Schaufler <casey@schaufler-ca.com> - 2015-07-16 05:00 +0200
          Re: [PATCH 0/7] Initial support for user namespace owned mounts Dave Chinner <david@fromorbit.com> - 2015-07-17 02:20 +0200
            Re: [PATCH 0/7] Initial support for user namespace owned mounts ebiederm@xmission.com (Eric W. Biederman) - 2015-07-17 02:50 +0200
              Re: [PATCH 0/7] Initial support for user namespace owned mounts Dave Chinner <david@fromorbit.com> - 2015-07-22 10:00 +0200
                Re: [PATCH 0/7] Initial support for user namespace owned mounts "J. Bruce Fields" <bfields@fieldses.org> - 2015-07-22 16:10 +0200
          Re: [PATCH 0/7] Initial support for user namespace owned mounts Colin Walters <walters@verbum.org> - 2015-07-20 20:00 +0200
      Re: [PATCH 0/7] Initial support for user namespace owned mounts Lukasz Pawelczyk <l.pawelczyk@samsung.com> - 2015-07-16 13:20 +0200
        Re: [PATCH 0/7] Initial support for user namespace owned mounts ebiederm@xmission.com (Eric W. Biederman) - 2015-07-17 02:20 +0200
          Re: [PATCH 0/7] Initial support for user namespace owned mounts Lukasz Pawelczyk <l.pawelczyk@samsung.com> - 2015-07-17 12:20 +0200

#1185033 — Re: [PATCH 0/7] Initial support for user namespace owned mounts

On 7/15/2015 12:46 PM, Seth Forshee wrote:
> These are the first in a larger set of patches that I've been working on
> (with help from Eric Biederman) to support mounting ext4 and fuse
> filesystems from within user namespaces. I've pushed the full series to:
>
>   git://kernel.ubuntu.com/sforshee/linux.git userns-mounts
>
> Taking the series as a whole, the strategy is to handle as much of the
> heavy lifting as possible in the vfs so the filesystems don't have to
> handle weird edge cases. If you look at the full series you'll find that
> the changes in ext4 to support user namespace mounts turn out to be
> fairly minimal (fuse is a bit more complicated though as it must deal
> with translating ids for a userspace process which is running in pid and
> user namespaces).
>
> The patches I'm sending today lay some of the groundwork in the vfs and
> related code. They fall into two broad groups:
>
>  1. Patches 1-2 add s_user_ns and simplify MNT_NODEV handling. These are
>     pretty straightforward, and Eric has expressed interest in merging
>     these patches soon. Note that patch 2 won't apply cleanly without
>     Eric's noexec patches for proc and sys [1].
>
>  2. Patches 2-7 tighten down security for mounts with s_user_ns !=
>     &init_user_ns. This includes updates to how file caps and suid are
>     handled and LSM updates to ignore security labels on superblocks
>     from non-init namespaces.
>
>     The LSM changes in particular may not be optimal, as I don't have a
>     lot of familiarity with this code, so I'd be especially appreciative
>     of review of these changes and suggestions on how to improve them.

Lukasz Pawelczyk <l.pawelczyk@samsung.com> proposed
LSM support in user namespaces ([RFC] lsm: namespace hooks)
that make a whole lot more sense than just turning off
the option of using labels on files. Gutting the ability
to use MAC in a namespace is a step down the road of
making MAC and namespaces incompatible.



>
> Subsequent patches will update the vfs for id translation, handling
> various corner cases, giving privileges to the user namsepace which owns
> a superblock, and finally supporting user namespace mounts for ext4 and
> fuse.
>
> Thanks,
> Seth
>
> [1] http://lkml.kernel.org/r/87mvz4yomp.fsf_-_@x220.int.ebiederm.org
>
>
> Andy Lutomirski (1):
>   fs: Treat foreign mounts as nosuid
>
> Eric W. Biederman (1):
>   userns: Simpilify MNT_NODEV handling.
>
> Seth Forshee (5):
>   fs: Add user namesapace member to struct super_block
>   fs: Ignore file caps in mounts from other user namespaces
>   security: Restrict security attribute updates for userns mounts
>   selinux: Ignore security labels on user namespace mounts
>   smack: Don't use security labels for user namespace mounts
>
>  fs/block_dev.c                 |  2 +-
>  fs/exec.c                      |  2 +-
>  fs/namei.c                     |  9 ++++++++-
>  fs/namespace.c                 | 34 ++++++++++++++++++++--------------
>  fs/proc/root.c                 |  3 ++-
>  fs/super.c                     | 38 +++++++++++++++++++++++++++++++++-----
>  include/linux/fs.h             |  9 +++++++++
>  include/linux/mount.h          |  1 +
>  include/linux/user_namespace.h |  8 ++++++++
>  kernel/user_namespace.c        | 14 ++++++++++++++
>  security/commoncap.c           |  4 +++-
>  security/security.c            | 10 +++++++++-
>  security/selinux/hooks.c       | 16 +++++++++++++++-
>  security/smack/smack_lsm.c     | 12 ++++++++++--
>  14 files changed, 134 insertions(+), 28 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
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/

[toc] | [next] | [standalone]

#1185054

Casey Schaufler <casey@schaufler-ca.com> writes:

> On 7/15/2015 12:46 PM, Seth Forshee wrote:
>> These are the first in a larger set of patches that I've been working on
>> (with help from Eric Biederman) to support mounting ext4 and fuse
>> filesystems from within user namespaces. I've pushed the full series to:
>>
>>   git://kernel.ubuntu.com/sforshee/linux.git userns-mounts
>>
>> Taking the series as a whole, the strategy is to handle as much of the
>> heavy lifting as possible in the vfs so the filesystems don't have to
>> handle weird edge cases. If you look at the full series you'll find that
>> the changes in ext4 to support user namespace mounts turn out to be
>> fairly minimal (fuse is a bit more complicated though as it must deal
>> with translating ids for a userspace process which is running in pid and
>> user namespaces).
>>
>> The patches I'm sending today lay some of the groundwork in the vfs and
>> related code. They fall into two broad groups:
>>
>>  1. Patches 1-2 add s_user_ns and simplify MNT_NODEV handling. These are
>>     pretty straightforward, and Eric has expressed interest in merging
>>     these patches soon. Note that patch 2 won't apply cleanly without
>>     Eric's noexec patches for proc and sys [1].
>>
>>  2. Patches 2-7 tighten down security for mounts with s_user_ns !=
>>     &init_user_ns. This includes updates to how file caps and suid are
>>     handled and LSM updates to ignore security labels on superblocks
>>     from non-init namespaces.
>>
>>     The LSM changes in particular may not be optimal, as I don't have a
>>     lot of familiarity with this code, so I'd be especially appreciative
>>     of review of these changes and suggestions on how to improve them.
>
> Lukasz Pawelczyk <l.pawelczyk@samsung.com> proposed
> LSM support in user namespaces ([RFC] lsm: namespace hooks)
> that make a whole lot more sense than just turning off
> the option of using labels on files. Gutting the ability
> to use MAC in a namespace is a step down the road of
> making MAC and namespaces incompatible.

This is not "turning off the option to use labels on files".

This is supporting mounting filesystems like ext4 by unprivileged users
and not trusting the labels they set in the same way as we trust labels
on filesystems mounted by privileged users.

The first step needs to be not trusting those labels and treating such
filesystems as filesystems without label support.  I hope that is Seth
has implemented.

In the long run we can do more interesting things with such filesystems
once the appropriate LSM policy is in place.

Getting s_user_ns present on struct super, properly set, and all of the
appropriate checks against it present in the vfs so that filesystems
don't need to duplicate logic is important if we are going do more
interesting things with user namespaces (as users have been asking for).

It is important for things as small as making it safe to allow
truly unprivileged users to mount fuse filesystems.

I am on the fence with Lukasz Pawelczyk's patches.  Some parts I liked
some parts I had issues with.  As I recall one of my issues was that
those patches conflicted in detail if not in principle with this
appropach.

If these patches do not do a good job of laying the ground work for
supporting security labels that unprivileged users can set than Seth
could really use some feedback.  Figuring out how to properly deal with
the LSMs has been one of his challenges.

I am hoping I can finishing working through the patches to fix the
semantics of rename and bind mounts before the next merge window opens,
so I can have enough cycles to lift the feature freeze on user
namespaces.  Except for maybe his first two patches (which fix a small
userspace API breakage) none of Seth's patches get to go in until I lift
the freeze.

Which is probably too much information but I hope this makes it clear
that the point of this work is as an enabler for future developments,
not as something to make user namespaces and LSMs incompatible.

Eric

--
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/

[toc] | [prev] | [next] | [standalone]

#1185065

On Wed, Jul 15, 2015 at 04:06:35PM -0500, Eric W. Biederman wrote:
> Casey Schaufler <casey@schaufler-ca.com> writes:
> 
> > On 7/15/2015 12:46 PM, Seth Forshee wrote:
> >> These are the first in a larger set of patches that I've been working on
> >> (with help from Eric Biederman) to support mounting ext4 and fuse
> >> filesystems from within user namespaces. I've pushed the full series to:
> >>
> >>   git://kernel.ubuntu.com/sforshee/linux.git userns-mounts
> >>
> >> Taking the series as a whole, the strategy is to handle as much of the
> >> heavy lifting as possible in the vfs so the filesystems don't have to
> >> handle weird edge cases. If you look at the full series you'll find that
> >> the changes in ext4 to support user namespace mounts turn out to be
> >> fairly minimal (fuse is a bit more complicated though as it must deal
> >> with translating ids for a userspace process which is running in pid and
> >> user namespaces).
> >>
> >> The patches I'm sending today lay some of the groundwork in the vfs and
> >> related code. They fall into two broad groups:
> >>
> >>  1. Patches 1-2 add s_user_ns and simplify MNT_NODEV handling. These are
> >>     pretty straightforward, and Eric has expressed interest in merging
> >>     these patches soon. Note that patch 2 won't apply cleanly without
> >>     Eric's noexec patches for proc and sys [1].
> >>
> >>  2. Patches 2-7 tighten down security for mounts with s_user_ns !=
> >>     &init_user_ns. This includes updates to how file caps and suid are
> >>     handled and LSM updates to ignore security labels on superblocks
> >>     from non-init namespaces.
> >>
> >>     The LSM changes in particular may not be optimal, as I don't have a
> >>     lot of familiarity with this code, so I'd be especially appreciative
> >>     of review of these changes and suggestions on how to improve them.
> >
> > Lukasz Pawelczyk <l.pawelczyk@samsung.com> proposed
> > LSM support in user namespaces ([RFC] lsm: namespace hooks)
> > that make a whole lot more sense than just turning off
> > the option of using labels on files. Gutting the ability
> > to use MAC in a namespace is a step down the road of
> > making MAC and namespaces incompatible.
> 
> This is not "turning off the option to use labels on files".
> 
> This is supporting mounting filesystems like ext4 by unprivileged users
> and not trusting the labels they set in the same way as we trust labels
> on filesystems mounted by privileged users.
> 
> The first step needs to be not trusting those labels and treating such
> filesystems as filesystems without label support.  I hope that is Seth
> has implemented.
> 
> In the long run we can do more interesting things with such filesystems
> once the appropriate LSM policy is in place.

Yes, this exactly. Right now it looks to me like the only safe thing to
do with mounts from unprivileged users is to ignore the security labels,
so that's what I'm trying to do with these changes. If there's some
better thing to do, or some better way to do it, I'm more than happy to
receive that feedback.

Seth
--
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/

[toc] | [prev] | [next] | [standalone]

#1185169

On Jul 15, 2015 3:34 PM, "Eric W. Biederman" <ebiederm@xmission.com> wrote:
>
> Seth Forshee <seth.forshee@canonical.com> writes:
>
> > On Wed, Jul 15, 2015 at 04:06:35PM -0500, Eric W. Biederman wrote:
> >> Casey Schaufler <casey@schaufler-ca.com> writes:
> >>
> >> > On 7/15/2015 12:46 PM, Seth Forshee wrote:
> >> >> These are the first in a larger set of patches that I've been working on
> >> >> (with help from Eric Biederman) to support mounting ext4 and fuse
> >> >> filesystems from within user namespaces. I've pushed the full series to:
> >> >>
> >> >>   git://kernel.ubuntu.com/sforshee/linux.git userns-mounts
> >> >>
> >> >> Taking the series as a whole, the strategy is to handle as much of the
> >> >> heavy lifting as possible in the vfs so the filesystems don't have to
> >> >> handle weird edge cases. If you look at the full series you'll find that
> >> >> the changes in ext4 to support user namespace mounts turn out to be
> >> >> fairly minimal (fuse is a bit more complicated though as it must deal
> >> >> with translating ids for a userspace process which is running in pid and
> >> >> user namespaces).
> >> >>
> >> >> The patches I'm sending today lay some of the groundwork in the vfs and
> >> >> related code. They fall into two broad groups:
> >> >>
> >> >>  1. Patches 1-2 add s_user_ns and simplify MNT_NODEV handling. These are
> >> >>     pretty straightforward, and Eric has expressed interest in merging
> >> >>     these patches soon. Note that patch 2 won't apply cleanly without
> >> >>     Eric's noexec patches for proc and sys [1].
> >> >>
> >> >>  2. Patches 2-7 tighten down security for mounts with s_user_ns !=
> >> >>     &init_user_ns. This includes updates to how file caps and suid are
> >> >>     handled and LSM updates to ignore security labels on superblocks
> >> >>     from non-init namespaces.
> >> >>
> >> >>     The LSM changes in particular may not be optimal, as I don't have a
> >> >>     lot of familiarity with this code, so I'd be especially appreciative
> >> >>     of review of these changes and suggestions on how to improve them.
> >> >
> >> > Lukasz Pawelczyk <l.pawelczyk@samsung.com> proposed
> >> > LSM support in user namespaces ([RFC] lsm: namespace hooks)
> >> > that make a whole lot more sense than just turning off
> >> > the option of using labels on files. Gutting the ability
> >> > to use MAC in a namespace is a step down the road of
> >> > making MAC and namespaces incompatible.
> >>
> >> This is not "turning off the option to use labels on files".
> >>
> >> This is supporting mounting filesystems like ext4 by unprivileged users
> >> and not trusting the labels they set in the same way as we trust labels
> >> on filesystems mounted by privileged users.
> >>
> >> The first step needs to be not trusting those labels and treating such
> >> filesystems as filesystems without label support.  I hope that is Seth
> >> has implemented.
> >>
> >> In the long run we can do more interesting things with such filesystems
> >> once the appropriate LSM policy is in place.
> >
> > Yes, this exactly. Right now it looks to me like the only safe thing to
> > do with mounts from unprivileged users is to ignore the security labels,
> > so that's what I'm trying to do with these changes. If there's some
> > better thing to do, or some better way to do it, I'm more than happy to
> > receive that feedback.
>
> Ugh.
>
> This made me realize that we have an interesting problem here.  An
> unprivileged mount of tmpfs probably needs to have
> s_user_ns == &init_user_ns.
>
> Otherwise we will break security labels on tmpfs for no good reason.
> ramfs and sysfs also seem to have similar concerns.
>
> Because they have no backing store we can trust those filesystems with
> security labels.  Plus for at least sysfs there is the security label
> bleed through issue, that we need to make certain works.
>
> Perhaps these filesystems with trusted backing store need to call
> "sget_userns(..., &init_user_ns)".
>
> If we don't get this right we will have significant regressions with
> respect to security labels, and that is not ok.

That's only a problem if there's anyone who sets security labels on
such a mount.  You need global caps to do that (I hope), which
requires someone outside the userns to help, which means there's a
good chance that literally no one does this.

--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/

[toc] | [prev] | [next] | [standalone]

#1185435

Andy Lutomirski <luto@amacapital.net> writes:

> On Jul 15, 2015 3:34 PM, "Eric W. Biederman" <ebiederm@xmission.com> wrote:
>>
>> Seth Forshee <seth.forshee@canonical.com> writes:
>>
>> > On Wed, Jul 15, 2015 at 04:06:35PM -0500, Eric W. Biederman wrote:
>> >> Casey Schaufler <casey@schaufler-ca.com> writes:
>> >>
>> >> > On 7/15/2015 12:46 PM, Seth Forshee wrote:
>> >> >> These are the first in a larger set of patches that I've been working on
>> >> >> (with help from Eric Biederman) to support mounting ext4 and fuse
>> >> >> filesystems from within user namespaces. I've pushed the full series to:
>> >> >>
>> >> >>   git://kernel.ubuntu.com/sforshee/linux.git userns-mounts
>> >> >>
>> >> >> Taking the series as a whole, the strategy is to handle as much of the
>> >> >> heavy lifting as possible in the vfs so the filesystems don't have to
>> >> >> handle weird edge cases. If you look at the full series you'll find that
>> >> >> the changes in ext4 to support user namespace mounts turn out to be
>> >> >> fairly minimal (fuse is a bit more complicated though as it must deal
>> >> >> with translating ids for a userspace process which is running in pid and
>> >> >> user namespaces).
>> >> >>
>> >> >> The patches I'm sending today lay some of the groundwork in the vfs and
>> >> >> related code. They fall into two broad groups:
>> >> >>
>> >> >>  1. Patches 1-2 add s_user_ns and simplify MNT_NODEV handling. These are
>> >> >>     pretty straightforward, and Eric has expressed interest in merging
>> >> >>     these patches soon. Note that patch 2 won't apply cleanly without
>> >> >>     Eric's noexec patches for proc and sys [1].
>> >> >>
>> >> >>  2. Patches 2-7 tighten down security for mounts with s_user_ns !=
>> >> >>     &init_user_ns. This includes updates to how file caps and suid are
>> >> >>     handled and LSM updates to ignore security labels on superblocks
>> >> >>     from non-init namespaces.
>> >> >>
>> >> >>     The LSM changes in particular may not be optimal, as I don't have a
>> >> >>     lot of familiarity with this code, so I'd be especially appreciative
>> >> >>     of review of these changes and suggestions on how to improve them.
>> >> >
>> >> > Lukasz Pawelczyk <l.pawelczyk@samsung.com> proposed
>> >> > LSM support in user namespaces ([RFC] lsm: namespace hooks)
>> >> > that make a whole lot more sense than just turning off
>> >> > the option of using labels on files. Gutting the ability
>> >> > to use MAC in a namespace is a step down the road of
>> >> > making MAC and namespaces incompatible.
>> >>
>> >> This is not "turning off the option to use labels on files".
>> >>
>> >> This is supporting mounting filesystems like ext4 by unprivileged users
>> >> and not trusting the labels they set in the same way as we trust labels
>> >> on filesystems mounted by privileged users.
>> >>
>> >> The first step needs to be not trusting those labels and treating such
>> >> filesystems as filesystems without label support.  I hope that is Seth
>> >> has implemented.
>> >>
>> >> In the long run we can do more interesting things with such filesystems
>> >> once the appropriate LSM policy is in place.
>> >
>> > Yes, this exactly. Right now it looks to me like the only safe thing to
>> > do with mounts from unprivileged users is to ignore the security labels,
>> > so that's what I'm trying to do with these changes. If there's some
>> > better thing to do, or some better way to do it, I'm more than happy to
>> > receive that feedback.
>>
>> Ugh.
>>
>> This made me realize that we have an interesting problem here.  An
>> unprivileged mount of tmpfs probably needs to have
>> s_user_ns == &init_user_ns.
>>
>> Otherwise we will break security labels on tmpfs for no good reason.
>> ramfs and sysfs also seem to have similar concerns.
>>
>> Because they have no backing store we can trust those filesystems with
>> security labels.  Plus for at least sysfs there is the security label
>> bleed through issue, that we need to make certain works.
>>
>> Perhaps these filesystems with trusted backing store need to call
>> "sget_userns(..., &init_user_ns)".
>>
>> If we don't get this right we will have significant regressions with
>> respect to security labels, and that is not ok.
>
> That's only a problem if there's anyone who sets security labels on
> such a mount.  You need global caps to do that (I hope), which
> requires someone outside the userns to help, which means there's a
> good chance that literally no one does this.

Fair enough.  That is however something we need to test.  If no one
puts security labels or file caps on such a mount we can change things.
If not we can't because it would introduce regressions.

Eric
--
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/

[toc] | [prev] | [next] | [standalone]

#1185165

On Wed, Jul 15, 2015 at 3:39 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 7/15/2015 2:06 PM, Eric W. Biederman wrote:
>> Casey Schaufler <casey@schaufler-ca.com> writes:
>
>> The first step needs to be not trusting those labels and treating such
>> filesystems as filesystems without label support.  I hope that is Seth
>> has implemented.
>
> A filesystem with Smack labels gets mounted in a namespace. The labels
> are ignored. Instead, the filesystem defaults (potentially specified as
> mount options smackfsdef="something", but usually the floor label ("_"))
> are used, giving the user the ability to read everything and (usually)
> change nothing. This is both dangerous (unintended read access to files)
> and pointless (can't make changes).

I don't get it.

If I mount an unprivileged filesystem, then either the contents were
put there *by me*, in which case letting me access them are fine, or
(with Seth's patches and then some) I control the backing store, in
which case I can do whatever I want regardless of what LSM thinks.

So I don't see the problem.  Why would Smack or any other LSM care at
all, unless it wants to prevent me from mounting the fs in the first
place?

--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/

[toc] | [prev] | [next] | [standalone]

#1185454

On 7/15/2015 6:08 PM, Andy Lutomirski wrote:
> On Wed, Jul 15, 2015 at 3:39 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 7/15/2015 2:06 PM, Eric W. Biederman wrote:
>>> Casey Schaufler <casey@schaufler-ca.com> writes:
>>> The first step needs to be not trusting those labels and treating such
>>> filesystems as filesystems without label support.  I hope that is Seth
>>> has implemented.
>> A filesystem with Smack labels gets mounted in a namespace. The labels
>> are ignored. Instead, the filesystem defaults (potentially specified as
>> mount options smackfsdef="something", but usually the floor label ("_"))
>> are used, giving the user the ability to read everything and (usually)
>> change nothing. This is both dangerous (unintended read access to files)
>> and pointless (can't make changes).
> I don't get it.
>
> If I mount an unprivileged filesystem, then either the contents were
> put there *by me*, in which case letting me access them are fine, or
> (with Seth's patches and then some) I control the backing store, in
> which case I can do whatever I want regardless of what LSM thinks.
>
> So I don't see the problem.  Why would Smack or any other LSM care at
> all, unless it wants to prevent me from mounting the fs in the first
> place?

First off, I don't cotton to the notion that you should be able
to mount filesystems without privilege. But it seems I'm being
outvoted on that. I suspect that there are cases where it might
be safe, but I can't think of one off the top of my head.

If you do mount a filesystem it needs to behave according to the
rules of the system. If you have a security module that uses
attributes on the filesystem you can't ignore them just because
it's "your data". Mandatory access control schemes, including
Smack and SELinux don't give a fig about who you are. It's the
label on the data and the process that matter. If "you" get to
muck the labels up, you've broken the mandatory access control.

> --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/

[toc] | [prev] | [next] | [standalone]

#1186339

On Wed, Jul 15, 2015 at 11:47:08PM -0500, Eric W. Biederman wrote:
> Casey Schaufler <casey@schaufler-ca.com> writes:
> > On 7/15/2015 6:08 PM, Andy Lutomirski wrote:
> >> If I mount an unprivileged filesystem, then either the contents were
> >> put there *by me*, in which case letting me access them are fine, or
> >> (with Seth's patches and then some) I control the backing store, in
> >> which case I can do whatever I want regardless of what LSM thinks.
> >>
> >> So I don't see the problem.  Why would Smack or any other LSM care at
> >> all, unless it wants to prevent me from mounting the fs in the first
> >> place?
> >
> > First off, I don't cotton to the notion that you should be able
> > to mount filesystems without privilege. But it seems I'm being
> > outvoted on that. I suspect that there are cases where it might
> > be safe, but I can't think of one off the top of my head.
> 
> There are two fundamental issues mounting filesystems without privielge,
> by which I actually mean mounting filesystems as the root user in a user
> namespace.
> 
> - Are the semantics safe.
> - Is the extra attack surface a problem.

I think the attack surface this exposes is the biggest problem
facing this proposal.

> Figuring out how to make semantics safe is what we are talking about.
> 
> Once we sort out the semantics we can look at the handful of filesystems
> like fuse where the extra attack surface is not a concern.
> 
> With that said desktop environments have for a long time been
> automatically mounting whichever filesystem you place in your computer,
> so in practice what this is really about is trying to align the kernel
> with how people use filesystems.

The key difference is that desktops only do this when you physically
plug in a device. With unprivileged mounts, a hostile attacker
doesn't need physical access to the machine to exploit lurking
kernel filesystem bugs. i.e. they can just use loopback mounts, and
they can keep mounting corrupted images until they find something
that works.

User namespaces are supposed to provide trust separation.  The
kernel filesystems simply aren't hardened against unprivileged
attacks from below - there is a trust relationship between root and
the filesystem in that they are the only things that can write to
the disk. Mounts from within a userns destroys this relationship as
the userns root, by definition, is not a trusted actor.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
--
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/

[toc] | [prev] | [next] | [standalone]

#1186349

Dave Chinner <david@fromorbit.com> writes:

> On Wed, Jul 15, 2015 at 11:47:08PM -0500, Eric W. Biederman wrote:
>> Casey Schaufler <casey@schaufler-ca.com> writes:
>> > On 7/15/2015 6:08 PM, Andy Lutomirski wrote:
>> >> If I mount an unprivileged filesystem, then either the contents were
>> >> put there *by me*, in which case letting me access them are fine, or
>> >> (with Seth's patches and then some) I control the backing store, in
>> >> which case I can do whatever I want regardless of what LSM thinks.
>> >>
>> >> So I don't see the problem.  Why would Smack or any other LSM care at
>> >> all, unless it wants to prevent me from mounting the fs in the first
>> >> place?
>> >
>> > First off, I don't cotton to the notion that you should be able
>> > to mount filesystems without privilege. But it seems I'm being
>> > outvoted on that. I suspect that there are cases where it might
>> > be safe, but I can't think of one off the top of my head.
>> 
>> There are two fundamental issues mounting filesystems without privielge,
>> by which I actually mean mounting filesystems as the root user in a user
>> namespace.
>> 
>> - Are the semantics safe.
>> - Is the extra attack surface a problem.
>
> I think the attack surface this exposes is the biggest problem
> facing this proposal.

I completely agree.

>> Figuring out how to make semantics safe is what we are talking about.
>> 
>> Once we sort out the semantics we can look at the handful of filesystems
>> like fuse where the extra attack surface is not a concern.
>> 
>> With that said desktop environments have for a long time been
>> automatically mounting whichever filesystem you place in your computer,
>> so in practice what this is really about is trying to align the kernel
>> with how people use filesystems.
>
> The key difference is that desktops only do this when you physically
> plug in a device. With unprivileged mounts, a hostile attacker
> doesn't need physical access to the machine to exploit lurking
> kernel filesystem bugs. i.e. they can just use loopback mounts, and
> they can keep mounting corrupted images until they find something
> that works.

Yep.  That magnifies the problem quite a bit.

> User namespaces are supposed to provide trust separation.  The
> kernel filesystems simply aren't hardened against unprivileged
> attacks from below - there is a trust relationship between root and
> the filesystem in that they are the only things that can write to
> the disk. Mounts from within a userns destroys this relationship as
> the userns root, by definition, is not a trusted actor.

I talked to Ted Tso a while back and ext4 is at least in principle
already hardened against that kind of attack.  I am not certain I
believe it, but if it is true I think it is fantastic.

At this point any setting of the FS_USER_MOUNT flag I figure needs to go
through the filesystem maintainers tree and they need to be aware of and
agree to deal with the attack from below issue.

The one filesystem I truly expect we can make work is fuse.  fuse has
been designed to deal with some variation of the attack from below issue
since day one.  We looked at what the patches to fuse would look like
with the current state of the vfs and it was not pretty.

We very much need to sort through as much as possible at the vfs layer,
and in generic code.  Allow everyone to see what is going on and how
it works before preceeding forward with enabling any filesystems.



I truly hope we can find a small set of block device filesystems that we
can harden from attack below.   That would allow linux to have serious
defenses against evil usb stick attacks.  I think that is going to take
a lot of careful coding, testing and validation and advancing the state
of the art to get there.

Eric
--
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/

[toc] | [prev] | [next] | [standalone]

#1189724

On Tue, Jul 21, 2015 at 01:37:21PM -0400, J. Bruce Fields wrote:
> On Fri, Jul 17, 2015 at 12:47:35PM +1000, Dave Chinner wrote:
> > On Thu, Jul 16, 2015 at 07:42:03PM -0500, Eric W. Biederman wrote:
> > > Dave Chinner <david@fromorbit.com> writes:
> > > > The key difference is that desktops only do this when you physically
> > > > plug in a device. With unprivileged mounts, a hostile attacker
> > > > doesn't need physical access to the machine to exploit lurking
> > > > kernel filesystem bugs. i.e. they can just use loopback mounts, and
> > > > they can keep mounting corrupted images until they find something
> > > > that works.
> > > 
> > > Yep.  That magnifies the problem quite a bit.
> > > 
> > > > User namespaces are supposed to provide trust separation.  The
> > > > kernel filesystems simply aren't hardened against unprivileged
> > > > attacks from below - there is a trust relationship between root and
> > > > the filesystem in that they are the only things that can write to
> > > > the disk. Mounts from within a userns destroys this relationship as
> > > > the userns root, by definition, is not a trusted actor.
> > > 
> > > I talked to Ted Tso a while back and ext4 is at least in principle
> > > already hardened against that kind of attack.  I am not certain I
> > > believe it, but if it is true I think it is fantastic.
> > 
> > No, it's not. No filesystem is, because to harden against such
> > attacks requires complete verification of all metadata when it is
> > read from disk, before it is used, or some method or ensuring the
> > block was not tampered with. CRCs are not sufficient, because they
> > can be tampered with, too.
> > 
> > The only way a filesystem would be able to trust what it reads from
> > disk has not been tampered with in a system with untrusted mounts is
> > if it has some kind of cryptographically secure signature in the
> > metadata and the attacker is unable to access the key for that
> > signature.
> 
> Preventing tampering is a little different from protecting the kernel
> from attack, isn't it?  I thought the latter was what people were asking
> about.

People might be asking for the latter, but the only attack vector
that can be made against filesystems from below is via tampering
with the on-disk structure.

An untrusted user in an untrusted container can construct arbitrary
untrusted filesystem structures and get them parsed by a context
running as $DIETY that assumes the structure is from a trusted
source.  What can possibly go wrong?

IOWs, To protect the kernel against attack from untrusted filesystem
images, we either have to be able to guarantee the image can not be
modified by untrusted parties (i.e.  needs to be created with
signed tools, contain only signed filesystem metadata and
signed/encrypted data), or we have to sandbox the filesystem parsing
code completely (i.e. fuse).

> So, for example, a screwed up on-disk directory structure shouldn't
> result in creating a cycle in the dcache and then deadlocking.

Therein lies the problem: how do you detect such structural defects
without doing a full structure validation? e.g. cyclic links may
only manifest when completely unrelated pieces of metadata are linked
together in a specific way.

Further, the problem is not restricted to validation at mount time -
if the user can write to the filesystem image file, then they can
modify it after it has been mounted, too. That means the attacker
may be someone who has broken into a container, not necessarily the
user you trusted with unprivileged mounts. That means every cold
metadata read needs to be treated with suspicion, not just at mount
time.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
--
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/

[toc] | [prev] | [next] | [standalone]

#1189978

On Wed, Jul 22, 2015 at 05:56:40PM +1000, Dave Chinner wrote:
> On Tue, Jul 21, 2015 at 01:37:21PM -0400, J. Bruce Fields wrote:
> > On Fri, Jul 17, 2015 at 12:47:35PM +1000, Dave Chinner wrote:
> > > On Thu, Jul 16, 2015 at 07:42:03PM -0500, Eric W. Biederman wrote:
> > > > Dave Chinner <david@fromorbit.com> writes:
> > > > > The key difference is that desktops only do this when you physically
> > > > > plug in a device. With unprivileged mounts, a hostile attacker
> > > > > doesn't need physical access to the machine to exploit lurking
> > > > > kernel filesystem bugs. i.e. they can just use loopback mounts, and
> > > > > they can keep mounting corrupted images until they find something
> > > > > that works.
> > > > 
> > > > Yep.  That magnifies the problem quite a bit.
> > > > 
> > > > > User namespaces are supposed to provide trust separation.  The
> > > > > kernel filesystems simply aren't hardened against unprivileged
> > > > > attacks from below - there is a trust relationship between root and
> > > > > the filesystem in that they are the only things that can write to
> > > > > the disk. Mounts from within a userns destroys this relationship as
> > > > > the userns root, by definition, is not a trusted actor.
> > > > 
> > > > I talked to Ted Tso a while back and ext4 is at least in principle
> > > > already hardened against that kind of attack.  I am not certain I
> > > > believe it, but if it is true I think it is fantastic.
> > > 
> > > No, it's not. No filesystem is, because to harden against such
> > > attacks requires complete verification of all metadata when it is
> > > read from disk, before it is used, or some method or ensuring the
> > > block was not tampered with. CRCs are not sufficient, because they
> > > can be tampered with, too.
> > > 
> > > The only way a filesystem would be able to trust what it reads from
> > > disk has not been tampered with in a system with untrusted mounts is
> > > if it has some kind of cryptographically secure signature in the
> > > metadata and the attacker is unable to access the key for that
> > > signature.
> > 
> > Preventing tampering is a little different from protecting the kernel
> > from attack, isn't it?  I thought the latter was what people were asking
> > about.
> 
> People might be asking for the latter, but the only attack vector
> that can be made against filesystems from below is via tampering
> with the on-disk structure.
> 
> An untrusted user in an untrusted container can construct arbitrary
> untrusted filesystem structures and get them parsed by a context
> running as $DIETY that assumes the structure is from a trusted
> source.  What can possibly go wrong?
> 
> IOWs, To protect the kernel against attack from untrusted filesystem
> images, we either have to be able to guarantee the image can not be
> modified by untrusted parties (i.e.  needs to be created with
> signed tools, contain only signed filesystem metadata and
> signed/encrypted data),

I don't think that works--who exactly would be the "trusted party"?  It
can't be this kernel or this hardware--users expect to be able to mount
filesystems created by older kernels, on other machines, running other
distributions (even other operating systems).  It can't be the
user--then any user could compromise the kernel by signing a bad
filesystem.

Authenticating the creator of the filesystem might be useful for other
reasons, but it sounds to me like at best only very weak protection
against corrupted filesystems.

As a similar example, browser makers are stuck both implementing SSL and
hardening their code against malicious content.  Those address separate
problems.

> or we have to sandbox the filesystem parsing
> code completely (i.e. fuse).
> 
> > So, for example, a screwed up on-disk directory structure shouldn't
> > result in creating a cycle in the dcache and then deadlocking.
> 
> Therein lies the problem: how do you detect such structural defects
> without doing a full structure validation?

You can prevent cycles in a graph if you can prevent adding an edge
which would be part of a cycle.

For the dcache, it's d_splice_alias that does that (using d_ancestor).

(And I believe the main motivation for that was NFS, where you don't
need a filesystem cycle, just a server-side race that can briefly make
it look like there's one--an example of the changing filesystem problem
that you point out below.)

> e.g. cyclic links may
> only manifest when completely unrelated pieces of metadata are linked
> together in a specific way.
>
> Further, the problem is not restricted to validation at mount time -
> if the user can write to the filesystem image file, then they can
> modify it after it has been mounted, too. That means the attacker
> may be someone who has broken into a container, not necessarily the
> user you trusted with unprivileged mounts. That means every cold
> metadata read needs to be treated with suspicion, not just at mount
> time.

Yes.  Agreed that this is difficult.  (I can't actually give an example
of an existing problem of this sort, but I'd be surprised if they don't
exist.)

--b.
--
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/

[toc] | [prev] | [next] | [standalone]

#1188403

On Thu, Jul 16, 2015, at 12:47 AM, Eric W. Biederman wrote:

> With that said desktop environments have for a long time been
> automatically mounting whichever filesystem you place in your computer,
> so in practice what this is really about is trying to align the kernel
> with how people use filesystems.

There is a large attack surface difference between mounting a device
that someone physically plugged into the computer (and note typically
it's required that the active console be unlocked as well[1]) versus
allowing any "unprivileged" process at any time to do it.

Many server setups use "unprivileged" uids that otherwise wouldn't
be able to exploit bugs in filesystem code.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=653520
"AutomountManager also keeps track of the current session availability
(using the ConsoleKit and gnome-screensaver DBus interfaces) and
inhibits mounting if the current session is locked, or another session
is in use instead."

--
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/

[toc] | [prev] | [next] | [standalone]

#1185735

On śro, 2015-07-15 at 16:06 -0500, Eric W. Biederman wrote:
> 
> I am on the fence with Lukasz Pawelczyk's patches.  Some parts I 
> liked
> some parts I had issues with.  As I recall one of my issues was that
> those patches conflicted in detail if not in principle with this
> appropach.
> 
> If these patches do not do a good job of laying the ground work for
> supporting security labels that unprivileged users can set than Seth
> could really use some feedback.  Figuring out how to properly deal 
> with
> the LSMs has been one of his challenges.

I fail to see how those 2 are in any conflict. Smack namespace is just
a mean of limiting the view of Smack labels within user namespace, to
be able to give some limited capabilities to processes in the namespace
to make it possible to partially administer Smack there. It doesn't
change Smack behaviour or mode of operation in any way.

If your approach here is to treat user ns mounted filesystem as if they
didn't support xattrs at all then my patches don't conflict here any
more than Smack itself already does.

If the filesystem will get a default (e.g. by smack* mount options)
label then this label will co-work with Smack namespaces.


-- 
Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics



--
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/

[toc] | [prev] | [next] | [standalone]

#1186343

Lukasz Pawelczyk <l.pawelczyk@samsung.com> writes:

> On śro, 2015-07-15 at 16:06 -0500, Eric W. Biederman wrote:
>> 
>> I am on the fence with Lukasz Pawelczyk's patches.  Some parts I 
>> liked
>> some parts I had issues with.  As I recall one of my issues was that
>> those patches conflicted in detail if not in principle with this
>> appropach.
>> 
>> If these patches do not do a good job of laying the ground work for
>> supporting security labels that unprivileged users can set than Seth
>> could really use some feedback.  Figuring out how to properly deal 
>> with
>> the LSMs has been one of his challenges.
>
> I fail to see how those 2 are in any conflict. 

Like I said.  They don't really conflict, and actually to really support
things well for smack we probably need something like your patches.

At the same time a patch written without dealing with s_user_ns is going
to going to fail to take a lot of important details into account.

Right now after fixing the mount namespace issues the top priority is to
work through the details and get s_user_ns implemented.  By that I mean
some version of patch 1 of Seth's series.

s_user_ns fundamentally changes how the concepts are represented in the
kernel in a way that is easier to secure, and that fundamentally better
matches things.  And sigh.  This review has shown we don't quite have
all of the details worked out.

> If your approach here is to treat user ns mounted filesystem as if they
> didn't support xattrs at all then my patches don't conflict here any
> more than Smack itself already does.

The end game if people developing smack choose to play, is to figure out
how to store your unmapped labels in a filesystem contained by a
user namespace and a smack label namespace root.

> If the filesystem will get a default (e.g. by smack* mount options)
> label then this label will co-work with Smack namespaces.

A default, but I don't know if it will be smack mount options that will
give that default.  The devil is in the details and there are a lot
of details.

Eric
--
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/

[toc] | [prev] | [next] | [standalone]

#1186671

On czw, 2015-07-16 at 19:10 -0500, Eric W. Biederman wrote:
> Lukasz Pawelczyk <l.pawelczyk@samsung.com> writes:
> > 
> > I fail to see how those 2 are in any conflict. 
> 
> Like I said.  They don't really conflict, and actually to really 
> support
> things well for smack we probably need something like your patches.

As far as I can see now from the discussion the best thing to do would
to be inherit label from a backing store object, or something along
this line.

> At the same time a patch written without dealing with s_user_ns is 
> going
> to going to fail to take a lot of important details into account.

I don't touch anything that would need to deal with s_user_ns. I also
don't change Smack's mounting logic in any way. My patches are
orthogonal to that.

> Right now after fixing the mount namespace issues the top priority is 
> to
> work through the details and get s_user_ns implemented.  By that I 
> mean
> some version of patch 1 of Seth's series.

My priority is to make Smack namespace work. This is a functionality
that has a perfectly valid use case now. Without it Smack in a
container is impossible to operate on.

> s_user_ns fundamentally changes how the concepts are represented in 
> the
> kernel in a way that is easier to secure, and that fundamentally 
> better
> matches things.  And sigh.  This review has shown we don't quite have
> all of the details worked out.
> 
> > If your approach here is to treat user ns mounted filesystem as if 
> > they
> > didn't support xattrs at all then my patches don't conflict here 
> > any
> > more than Smack itself already does.
> 
> The end game if people developing smack choose to play, is to figure 
> out
> how to store your unmapped labels in a filesystem contained by a
> user namespace and a smack label namespace root.

Storing an unmapped label (read: real label) in Smack namespace is
exactly the same as it is now without the namespace. I always store the
real label.

The problem here is: what real label should be "read" and eventually
stored in that filesystem (see my first comment here). Again, Smack
namespace doesn't touch that logic.

> > If the filesystem will get a default (e.g. by smack* mount options)
> > label then this label will co-work with Smack namespaces.
> 
> A default, but I don't know if it will be smack mount options that 
> will
> give that default.  The devil is in the details and there are a lot
> of details.

Now Smack gives the default. If someone will modify Smack to give a
different label because of s_user_ns support Smack namepace will not
cause any hindrance here.

Smack namespace main role is only to be able to operate Smack within a
container. All the other LSM can do that already as they don't require
caps to operate normally. Smack does. Hence it had to be namespaced in
some way to give limited capabilities in a container (user ns).

This really has nothing to do with the way Smack mounts, assigns
labels, decides what is allowed and what is not, etc.

What this discussion is about is how to modify or even bend LSM's way
of work to make unprivileged user ns mounts work under LSM (or not).
Smack namespace here is just an utility within Smack itself. And maybe
it can be used to help this at some point, but beyond that it's
orthogonal to the problem.



-- 
Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics



--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web