On Mon, Jul 08, 2019 at 09:02:10PM +0900, Tetsuo Handa wrote: > Hello, David Howells. > > I realized via https://lwn.net/Articles/792622/ that a new set of > system calls for filesystem mounting has been added to Linux 5.2. But > I feel that LSM modules are not ready to support these system calls. > > An example is move_mount() added by this patch. This patch added > security_move_mount() LSM hook but none of in-tree LSM modules are > providing "LSM_HOOK_INIT(move_mount, ...)" entry. Therefore, currently > security_move_mount() is a no-op. At least for TOMOYO, I want to check > mount manipulations caused by system calls because allowing mounts on > arbitrary location is not acceptable for pathname based access control. > What happened? I want TOMOYO to perform similar checks like mount() does. That would be like tomoyo_check_mount_acl(), right? if (need_dev) { /* Get mount point or device file. */ if (!dev_name || kern_path(dev_name, LOOKUP_FOLLOW, &path)) { error = -ENOENT; goto out; } obj.path1 = path; requested_dev_name = tomoyo_realpath_from_path(&path); if (!requested_dev_name) { error = -ENOENT; goto out; } } else { is an obvious crap for *ALL* cases. You are doing pathname resolution, followed by normalization and checks. Then the result of said pathname resolution is thrown out and it's redone (usually by something in fs/super.c). Results of _that_ get used. Could you spell TOCTOU? And yes, exploiting that takes a lot less than being able to do mount(2) in the first place - just pass it /proc/self/fd/69/<some acceptable path>/. with descriptor refering to opened root directory. With ~/<some acceptable path> being a symlink to whatever you actually want to hit. And descriptor 42 being your opened homedir. Now have that call of mount(2) overlap with dup2(42, 69) from another thread sharing your descriptor table. It doesn't take much to get the timing right, especially if you can arrange for some other activity frequently hitting namespace_sem at least shared (e.g. reading /proc/mounts in a loop from another process); that's likely to stall mount(2) at the point of lock_mount(), which comes *AFTER* the point where LSM hook is stuck into. Again, *ANY* checks on "dev_name" in ->sb_mount() instances are so much snake oil. Always had been.
