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

Groups > linux.kernel > #1273452 > unrolled thread

Re: [RFC] namei: prevent sgid-hardlinks for unmapped gids

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: [RFC] namei: prevent sgid-hardlinks for unmapped gids Kees Cook <keescook@chromium.org> - 2015-11-19 21:20 +0100
    Re: [RFC] namei: prevent sgid-hardlinks for unmapped gids Andy Lutomirski <luto@amacapital.net> - 2015-11-19 23:00 +0100
    Re: [RFC] namei: prevent sgid-hardlinks for unmapped gids Dave Chinner <david@fromorbit.com> - 2015-11-19 23:10 +0100
      Re: [RFC] namei: prevent sgid-hardlinks for unmapped gids Kees Cook <keescook@chromium.org> - 2015-11-20 01:20 +0100

#1273452 — Re: [RFC] namei: prevent sgid-hardlinks for unmapped gids

On Tue, Nov 10, 2015 at 7:08 AM, Jan Kara <jack@suse.cz> wrote:
> On Sat 07-11-15 21:02:06, Ted Tso wrote:
>> On Fri, Nov 06, 2015 at 09:05:57PM -0800, Kees Cook wrote:
>> > >>>> They're certainly not used early enough -- we need to remove suid when
>> > >>>> the page becomes writable via mmap (wp_page_shared), not when
>> > >>>> writeback happens, or at least not only when writeback happens.
>> > >>>
>> > >>> Well, I'm shy about the change there. For example, we don't strip in
>> > >>> on open(RDWR), just on write().
>> > >>
>> > >> I take it back. Hooking wp_page_shared looks expensive. :) Maybe we do
>> > >> need to hook the mmap?
>> > >
>> > > But file_update_time already pokes at the same (or nearby) cachelines,
>> > > I think -- why would it be expensive?  The whole thing could be
>> > > guarded by if (unlikely(is setuid)), right?
>> >
>> > Yeah, true. I added file_remove_privs calls near all the
>> > file_update_time calls, to no effect. Added to wp_page_shared too,
>> > nothing. Hmmm.
>>
>> Why not put the the should_remove_suid() call in
>> filemap_page_mkwrite(), or maybe do_page_mkwrite()?
>
> page_mkwrite() callbacks are IMHO the right place for this check (and
> change).  Just next to file_update_time() call. You get proper filesystem

Should file_update_time() just be modified to include
file_remove_privs()? They seem to regularly go together.

> freezing protection etc. As Ted properly mentions filemap_page_mkwrite() is
> one place you want to hook into but quite a few filesystems (most notably
> ext4, xfs, btrfs) overload ->page_mkwrite() callbacks to their own
> functions so each filesystem that does this needs to be updated
> separately...

Depending on each filesystem to do this correctly seems like a
mistake. I was surprised that my attempts (via file_update_time and
wp_page_shared) didn't work. Any other suggestions?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
--
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]

#1273530

On Nov 19, 2015 12:11 PM, "Kees Cook" <keescook@chromium.org> wrote:
>
> On Tue, Nov 10, 2015 at 7:08 AM, Jan Kara <jack@suse.cz> wrote:
> > On Sat 07-11-15 21:02:06, Ted Tso wrote:
> >> On Fri, Nov 06, 2015 at 09:05:57PM -0800, Kees Cook wrote:
> >> > >>>> They're certainly not used early enough -- we need to remove suid when
> >> > >>>> the page becomes writable via mmap (wp_page_shared), not when
> >> > >>>> writeback happens, or at least not only when writeback happens.
> >> > >>>
> >> > >>> Well, I'm shy about the change there. For example, we don't strip in
> >> > >>> on open(RDWR), just on write().
> >> > >>
> >> > >> I take it back. Hooking wp_page_shared looks expensive. :) Maybe we do
> >> > >> need to hook the mmap?
> >> > >
> >> > > But file_update_time already pokes at the same (or nearby) cachelines,
> >> > > I think -- why would it be expensive?  The whole thing could be
> >> > > guarded by if (unlikely(is setuid)), right?
> >> >
> >> > Yeah, true. I added file_remove_privs calls near all the
> >> > file_update_time calls, to no effect. Added to wp_page_shared too,
> >> > nothing. Hmmm.
> >>
> >> Why not put the the should_remove_suid() call in
> >> filemap_page_mkwrite(), or maybe do_page_mkwrite()?
> >
> > page_mkwrite() callbacks are IMHO the right place for this check (and
> > change).  Just next to file_update_time() call. You get proper filesystem
>
> Should file_update_time() just be modified to include
> file_remove_privs()? They seem to regularly go together.
>

No, I think.  The current file_update_time is slow and
POSIX-noncompliant, and I have old patches I need to dig up to fix it.

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

#1273540

On Thu, Nov 19, 2015 at 12:11:11PM -0800, Kees Cook wrote:
> On Tue, Nov 10, 2015 at 7:08 AM, Jan Kara <jack@suse.cz> wrote:
> > On Sat 07-11-15 21:02:06, Ted Tso wrote:
> >> On Fri, Nov 06, 2015 at 09:05:57PM -0800, Kees Cook wrote:
> >> > >>>> They're certainly not used early enough -- we need to remove suid when
> >> > >>>> the page becomes writable via mmap (wp_page_shared), not when
> >> > >>>> writeback happens, or at least not only when writeback happens.
> >> > >>>
> >> > >>> Well, I'm shy about the change there. For example, we don't strip in
> >> > >>> on open(RDWR), just on write().
> >> > >>
> >> > >> I take it back. Hooking wp_page_shared looks expensive. :) Maybe we do
> >> > >> need to hook the mmap?
> >> > >
> >> > > But file_update_time already pokes at the same (or nearby) cachelines,
> >> > > I think -- why would it be expensive?  The whole thing could be
> >> > > guarded by if (unlikely(is setuid)), right?
> >> >
> >> > Yeah, true. I added file_remove_privs calls near all the
> >> > file_update_time calls, to no effect. Added to wp_page_shared too,
> >> > nothing. Hmmm.
> >>
> >> Why not put the the should_remove_suid() call in
> >> filemap_page_mkwrite(), or maybe do_page_mkwrite()?
> >
> > page_mkwrite() callbacks are IMHO the right place for this check (and
> > change).  Just next to file_update_time() call. You get proper filesystem
> 
> Should file_update_time() just be modified to include
> file_remove_privs()? They seem to regularly go together.

They might have similar call sites, but they are completely
different operations. timestamp updates are optional, highly
configurable and behaviour is filesystem implementation specific,
whilst file_remove_privs() is mandatory and must be done in a
crash-safe manner (i.e. via transactions). Hence, IMO, they need to
be kept separate even if the call sites are similar.

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]

#1273621

On Thu, Nov 19, 2015 at 2:02 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Thu, Nov 19, 2015 at 12:11:11PM -0800, Kees Cook wrote:
>> On Tue, Nov 10, 2015 at 7:08 AM, Jan Kara <jack@suse.cz> wrote:
>> > On Sat 07-11-15 21:02:06, Ted Tso wrote:
>> >> On Fri, Nov 06, 2015 at 09:05:57PM -0800, Kees Cook wrote:
>> >> > >>>> They're certainly not used early enough -- we need to remove suid when
>> >> > >>>> the page becomes writable via mmap (wp_page_shared), not when
>> >> > >>>> writeback happens, or at least not only when writeback happens.
>> >> > >>>
>> >> > >>> Well, I'm shy about the change there. For example, we don't strip in
>> >> > >>> on open(RDWR), just on write().
>> >> > >>
>> >> > >> I take it back. Hooking wp_page_shared looks expensive. :) Maybe we do
>> >> > >> need to hook the mmap?
>> >> > >
>> >> > > But file_update_time already pokes at the same (or nearby) cachelines,
>> >> > > I think -- why would it be expensive?  The whole thing could be
>> >> > > guarded by if (unlikely(is setuid)), right?
>> >> >
>> >> > Yeah, true. I added file_remove_privs calls near all the
>> >> > file_update_time calls, to no effect. Added to wp_page_shared too,
>> >> > nothing. Hmmm.
>> >>
>> >> Why not put the the should_remove_suid() call in
>> >> filemap_page_mkwrite(), or maybe do_page_mkwrite()?
>> >
>> > page_mkwrite() callbacks are IMHO the right place for this check (and
>> > change).  Just next to file_update_time() call. You get proper filesystem
>>
>> Should file_update_time() just be modified to include
>> file_remove_privs()? They seem to regularly go together.
>
> They might have similar call sites, but they are completely
> different operations. timestamp updates are optional, highly
> configurable and behaviour is filesystem implementation specific,
> whilst file_remove_privs() is mandatory and must be done in a
> crash-safe manner (i.e. via transactions). Hence, IMO, they need to
> be kept separate even if the call sites are similar.

Yeah, that was my worry too.

Okay, I think I've got it now. I had misunderstood the purpose of the
page_mkwrite variable in wp_page_reuse. My tests pass now. Patch on
it's way...

-Kees

>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com



-- 
Kees Cook
Chrome OS Security
--
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