Apps for GNOME desktops [LWN.net]

Apps for GNOME desktops

Posted Aug 8, 2013 8:15 UTC (Thu) by Frej (guest, #4165)
Parent article: Apps for GNOME desktops

In Step four:

>On Linux, he said, they would probably involve compressing multiple filesystem partitions—which would then be mounted to the system with a loopback filesystem

This seems to make every kernel fs code an attack vector?
Note: I'm clueless about the details here.

to post comments

Apps for GNOME desktops

Posted Aug 8, 2013 10:00 UTC (Thu) by khim (subscriber, #9252) [Link]

This is very valid concern, actually: I know that few years back it was really easy to create kernel panic (and probably exploit) with a corrupt filesystem.

Note that while Android uses something like this to run applications from SD card it's implemented differently: applications are distributed as ZIP files (and even that is problematic, although less problematic then FAT/EXT4/whatever filesystem) and then filesystem is created on device before start of the program.

Apps for GNOME desktops

Posted Aug 8, 2013 10:14 UTC (Thu) by alexl (guest, #19068) [Link] (1 responses)

This code is already an attack vector with the recent user mount namespaces where non-privileged users can loopback mount any file.

Apps for GNOME desktops

Posted Aug 8, 2013 12:40 UTC (Thu) by Frej (guest, #4165) [Link]

Meh!...

I'd assume user mount namespace are a relatively manual process involving a terminal? Ie. practically only useful for privilege escalation, since it is would be relatively obscure to scam someone to loopback mount a file. The App approach would at least automate some of this, making the scamming/remote process less of a chore and therefore more viable for a remote exploit?

Either way, I highly applaud the goal :).

Apps for GNOME desktops

Posted Aug 8, 2013 18:21 UTC (Thu) by iabervon (subscriber, #722) [Link]

I think using a different filesystem from the ones that are commonly used for hard drive partitions would mostly solve this. It's relatively easy to design a filesystem that's only feasible to write once but can be read without relying on any tricky consistency assumptions. Also, some filesystem implementations make the assumption that, if the filesystem is terribly corrupt, the system is already unstable, which makes some sense for filesystem types that people store their kernels on, but would not be true of a filesystem for apps.

Microkernel?

Posted Aug 9, 2013 15:04 UTC (Fri) by cesarb (subscriber, #6266) [Link] (2 responses)

A way to avoid this problem would be to run the filesystem code in userspace (like on Hurd), and sandbox the filesystem code together with the application. That way, crashing the filesystem would only be able to give the application as much privilege as it already has.

Microkernel?

Posted Aug 12, 2013 18:57 UTC (Mon) by drag (guest, #31333) [Link] (1 responses)

You still have to expose the kernel file system interfaces, like they do with FUSE, if you want a POSIX interface to those file systems.

Maybe FUSE is the answer. It would be very simple to expose a tar.gz archive as a read-only file system using a FUSE module. You can make extremely simple and that way it should minimize the amount of problems you could have with it.

The downside is, of course, that FUSE is a potential security hole itself.

Maybe a 'FUSE-lite' that exposes only what is absolutely needed to make a read-only user space file system?

Microkernel?

Posted Aug 15, 2013 18:33 UTC (Thu) by rwmj (subscriber, #5474) [Link]

I think you're looking for libguestfs.