Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: > 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. Al you do realize that the TOCTOU you are talking about comes the system call API. TOMOYO can only be faulted for not playing in their own sandbox and not reaching out and fixing the vfs implementation details. Userspace has always had to very careful to only mount filesystems on paths that root completely controls and won't change. Further system calls for manipulating the mount tree have historically done a crap job of validating their inputs. Relying on the fact that only root can call them. So the idea of guarding against root doing something silly was silly. So I figure at the end of the day if the new security hooks for the new mount system calls don't make it possible to remove the TOCTOU that is on you and Dave. You two touched that code last after all. Not updating the new security hooks to at least do as good a job as the old security hooks is the definition of regression. So Al. Please simmer down and take the valid criticism. Eric
