On 02/27/2018 02:23 AM, Al Viro wrote: > On Tue, Feb 27, 2018 at 12:57:21AM +0000, Al Viro wrote: >> On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote: >>> The function current_nameidata_security(struct inode *) can be used to >>> retrieve a blob's pointer address tied to the inode being walk through. >>> This enable to follow a path lookup and know where an inode access come >>> from. This is needed for the Landlock LSM to be able to restrict access >>> to file path. >>> >>> The LSM hook nameidata_free_security(struct inode *) is called before >>> freeing the associated nameidata. >> >> NAK. Not without well-defined semantics and "some Linux S&M uses that for >> something, don't ask what" does not count. > > Incidentally, pathwalk mechanics is subject to change at zero notice, so > if you want something, you'd better > * have explicitly defined semantics > * explain what it is - on fsdevel > * not have it hidden behind the layers of opaque LSM dreck, pardon > the redundance. > > Again, pathwalk internals have changed in the past and may bloody well > change again in the future. There's a damn good reason why struct nameidata > is _not_ visible outside of fs/namei.c, and quietly relying upon any > implementation details is no-go. > I thought this whole patch series would go to linux-fsdevel but only this patch did. I'll CCed fsdevel for the next round. Meanwhile, the cover letter is here: https://lkml.org/lkml/2018/2/26/1214 The code using current_nameidata_lookup(inode) is in the patch 07/11: https://lkml.org/lkml/2018/2/26/1206 To sum up, I don't know any way to identify if a directory (execute) access was directly requested by a process or inferred by the kernel because of a path walk. This was not needed until now because the other access control systems (either the DAC or access controls enforced by inode-based LSM, i.e. SELinux and Smack) do not care about the file hierarchy. Path-based access controls (i.e. AppArmor and Tomoyo) directly use the notion of path to define a security policy (in the kernel, not only in the user space configuration). Landlock can't rely on xattrs (because of composed and unprivileged access control). Because we can't know for sure from which path an inode come from (if any), path-based LSM hooks do not help for some file system checks (e.g. inode_permission). With Landlock, I try to find a way to identify a set of inodes, from the user space point of view, which is most of the time related to file hierarchies. I needed a way to "follow" a path walk, with the minimum amount of code, and if possible without touching the fs/namei.c . I saw that the pathwalk mechanism has evolved over time. With this patch, I tried to make a kernel object (nameidata) usable in some way by LSM, but only through an inode (current_nameidata_lookup(inode)). The "only" guarantee of this function should be to identify if an inode is tied to a path walk. This enable to follow a path walk and know why an inode access is requested. I get your concern about the "instability" of the path walk mechanism. However, I though that a path resolution should not change from the user space point of view, like other Linux ABI. Anyway, all the current inode-based access controls, including DAC, rely on this path walks mechanism. This patch does not expose anything to user space, but only through the API of Landlock, which is currently relying on path walk resolutions, already visible to user space. Did I miss something? Do you have another suggestion to tie an inode to a path walk? Thanks, Mickaël
Attachment:
signature.asc
Description: OpenPGP digital signature
