On Fri, Aug 15, 2014 at 12:05 PM, Serge Hallyn <serge.hallyn@xxxxxxxxxx> wrote:
> Quoting Andy Lutomirski (luto@xxxxxxxxxxxxxx):
>> Currently, creating a new mount (as opposed to bindmount) in a
>> non-root userns will implicitly set nodev unless the fs is devpts.
>> Something like this will be necessary for file systems that allow
>> the mounter to create device nodes without using mknod (e.g. FUSE
>> if/when that is allowed), but none of the currently allowed
>> filesystems do this.
>
> Hi,
>
> Sorry, I'm probably thinking stupidly, but I don't see this restriction
> being the case
>
> serge@sl:~$ mount | grep tmp
> [...]
> tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
> serge@sl:~$ sudo mknod /run/kvm c 10 232
> [sudo] password for serge:
> serge@sl:~$ echo $?
> 0
> serge@sl:~$ ls -l /run/kvm
> crw-r--r-- 1 root root 10, 232 Aug 15 14:04 /run/kvm
>
> But you seem to be saying I shouldn't be allowed to create a device inside
> a tmpfs. What am I overlooking?
I assume you're in the root userns. This patch is unnecessary, and
has no effect, if you're in the root userns.
The code in Sandstorm that's currently broken in Linus' tree runs in a
new userns with a matching mount ns. It does (copied verbatim):
KJ_SYSCALL(mount("sandstorm-dev", "dev", "tmpfs", MS_NOSUID | MS_NOEXEC,
"size=1m,nr_inodes=16,mode=755"));
makeCharDeviceNode("null", "null", 1, 3);
makeCharDeviceNode("zero", "zero", 1, 5);
makeCharDeviceNode("random", "urandom", 1, 9);
makeCharDeviceNode("urandom", "urandom", 1, 9);
KJ_SYSCALL(mount("dev", "dev", nullptr,
MS_REMOUNT | MS_BIND | MS_NOSUID | MS_NOEXEC |
MS_RDONLY, nullptr));
makeCharDeviceNode is a helper that creates an empty file and mounts a
device node over it. This code needs the fs to be read/write, but
Sandstorm wants to make /dev read-only when it's done.
In Linus' tree, the remount fails with -EPERM because the mount is
secretly nodev. It was always secretly nodev, but no one noticed
because of CVE-2014-5207, which caused that remount to succeed.
(Yay for programs that inadvertently exploited a serious security
vulnerability for their normal function.)
--Andy
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html