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.