lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 16 Sep 2014 12:26:27 -0500 From: Seth Forshee <seth.forshee@...onical.com> To: Shea Levy <shea@...alevy.com> Cc: linux-kernel@...r.kernel.org, lxc-devel@...ts.linuxcontainers.org Subject: Re: [RFC PATCH 0/2] Loop device psuedo filesystem On Tue, Sep 16, 2014 at 01:05:48PM -0400, Shea Levy wrote: > On Tue, Sep 16, 2014 at 11:39:57AM -0500, Seth Forshee wrote: > > On Tue, Sep 16, 2014 at 12:12:47PM -0400, Shea Levy wrote: > > > OK, compiling with BLK_DEV_LOOP=y (on top of 3.16.2), I was able to > > > mount loopfs, request a loop device from loop-control, and associate it > > > with an image with an ext4 partition with losetup, but mount still gives > > > EPERM (all as root in a userns started from an unprivileged account). Is > > > this expected? I do have read and write permissions to the resultant > > > loop device. If this is expected, what would be needed to be able to > > > mount the device? > > > > Yes. Very few filesystems allow mounting from a userns right now, and > > probably no "regular" filesystems do, only special filesystems like > > sysfs. At minimum you'll need to add the FS_USERNS_MOUNT flag to any > > filesystems you want to use, but even then the user/group ids probably > > won't be translated into the userns. > > > > Hm, I see. Yeah, none of the 'regular' filesystems have that set. Why is > that, if it's easy to explain? From a naive perspective it seems like if > you have the permissions to the device then the uid/gid mapping should > be generic (the on-disk id is the id *inside* the namespace, the kernel > maps that based on the id_map file to processes outside the namespace), > but I'm sure that's insecure in a way I'm not seeing. Security. There are likely some bugs in how filesystem data is processed, and if an arbitrary user can hand the kernel specially crafted filesystem images these bugs could become exploits. I suspect that some filesystems will be mountable from user namespaces eventually, I just don't think anyone has done the work to alleviate the security concerns yet. > > > Also, this isn't an issue exactly, but the free devices started at 8 > > > (presumably because I have /dev/loop[0-7]) and appear in /dev in the > > > root ns (presumably via udev) until I unmounted. > > > > Right. 0-7 get created at module init time and end up allocated to the > > init_user_ns superblock, so the first "free" id for your ns is 8. > > > > I've brought up the problem of the devices for the userns also showing > > up in devtmpfs. It was dismissed as not really being an issue, though I > > still don't agree with that viewpoint. My proposed solution of assigning > > devices to namespaces and then creating a namespaced devtmpfs was > > rejected as well. > > > > Just so you know, I'm not doing any further development of these patches > > right now. I've shifted my efforts to getting fuse mountable from user > > namespaces (https://lkml.org/lkml/2014/9/12/367). > > > > Aside from the patch to build as a module, is there anything further to > be done on the loopfs side of things? If not I may try to get this > merged myself if you don't mind. No, I don't mind. There's probably some cleanup to do. I don't recall if I had resolved all the issues with getting the loop devices "freed" when a superblock was killed, which was kind of tricky to get right. Obviously I never tested unloading the module either ;-) Also go back through the thread and read the feedback the patches got. There was a suggestion to leave loop alone and create something new for this purpose as well. There may be more, but that's what comes to mind. I also wanted to somehow make the devices which are in a non-root loopfs mount not show up in devtmpfs, but I still needed to come up with a way to do that which Greg would be happy with. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists