linux-kernel - Re: [PATCH 4/9] Implement fsopen() to prepare for a mount

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 09 May 2017 00:09:55 +0100
From:   David Howells <dhowells@...hat.com>
To:     Miklos Szeredi <mszeredi@...hat.com>
Cc:     dhowells@...hat.com, viro <viro@...iv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-nfs@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/9] Implement fsopen() to prepare for a mount

Miklos Szeredi <mszeredi@...hat.com> wrote:

> Someone also suggested using /dev/fs/${FSTYPE} to open the fsfd.

The downside of using open() for this is that you then have a chicken-and-egg
problem with respect to booting as you point out.

> I realize that does not have the namespace info that you also want to add,
> but wondering if that really has to come from open and cannot be set later?

When do you do the security checks?  Those are going to be affected by the
namespaces.  Other things are as well, such as setting hostnames, IP
addresses, device file paths and default UIDs/GIDs, but these are probably
more okay with being deferred to the parameter validation step.

> ALTERNATIVES are /proc/fs/${FSTYPE}/dev or /sys/fs/${FSTYPE}/dev.
> 
> Obviously neither can be used for bootstraping but there's still old
> mount(2) for that.

It should also be possible to build-time disable mount(2) in future.
Obviously, this would mean providing other vectors for the other functions of
mount(2).

David