Re: How do we store/install apps?

[Greg KH <gregkh linuxfoundation org>]

On Fri, Oct 10, 2014 at 02:38:44PM +0200, Alexander Larsson wrote:
> On fre, 2014-10-10 at 14:26 +0200, Alexander Larsson wrote:
> > On fre, 2014-10-10 at 05:10 -0700, Greg KH wrote:
> > > On Fri, Oct 10, 2014 at 01:52:05PM +0200, Alexander Larsson wrote:
> > > > * Don't pass untrusted data to the kernel. For instance, it is risky
> > > >   to download raw filesystem data and then mount that, or mount a
> > > >   loopback file that the user can modify. The raw filesystem data is
> > > >   directly parsed by the kernel and weird data there can cause kernel
> > > >   panics.
> > >
> > > If that happens, the kernel is doing something wrong, and needs to be
> > > fixed :)
> > >
> > > Seriously, if you know of any such bugs, please let the kernel
> > > developers know and they will be fixed, just like we've fixed this same
> > > type of bug many many times in the past.
> > >
> > > So don't worry too much about this one, it shouldn't be an issue.
> >
> > Sure, it *should* not happen. But empirically it does. For instance
> > there was this recent mail:
> >
> > https://lists.fedoraproject.org/pipermail/devel/2014-October/203101.html
> >
> > Where light fuzzing of a btrfs filesystem caused pretty bad behaviour in
> > many cases. I also know people who had similar issues with btrfs on
> > usbdisks that where bad.

That's not good, and needs to be fixed in btrfs anyway, as any user can
mount a btrfs filesystem on a USB disk with no additional permissions
needed.

> > Can you imagine instead of random fuzzying someone was actively trying
> > to attach the kernel code by creating creative invalid file systems.
> > These codepaths are *not* well tested or reviewed...

Maybe not in btrfs, but in lots of other filesystems those codepaths are
well tested and reviewed.  Heck, I have had to fix lots of odd
filesystems myself in that area when it was pointed out there were
problems in them.

> Also, your own comment "just like we've fixed this same type of bug many
> many times in the past" makes one less than confident...

There will always be bugs, I said that because the kernel security team
treats this type of bug very seriously and will work to fix it wherever
found.  You _should_ be able to rely on mounting an arbitrary filesystem
image with no issues.

thanks,

greg k-h