| Message ID | 20180227004121.3633-2-mic@digikod.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mickaël,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Micka-l-Sala-n/Landlock-LSM-Toward-unprivileged-sandboxing/20180228-233659
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: x86_64-randconfig-x017-201808 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from fs//quota/dquot.c:74:0:
>> include/linux/security.h:815:10: warning: 'struct nameidata_lookup' declared inside parameter list will not be visible outside of this definition or declaration
struct nameidata_lookup *lookup, struct inode *inode)
^~~~~~~~~~~~~~~~
vim +815 include/linux/security.h
813
814 static inline void security_nameidata_put_lookup(
> 815 struct nameidata_lookup *lookup, struct inode *inode)
816 { }
817
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hi Mickaël,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Micka-l-Sala-n/Landlock-LSM-Toward-unprivileged-sandboxing/20180228-233659
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: i386-randconfig-a1-201808 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from init/main.c:37:0:
>> include/linux/security.h:815:43: warning: 'struct nameidata_lookup' declared inside parameter list
struct nameidata_lookup *lookup, struct inode *inode)
^
>> include/linux/security.h:815:43: warning: its scope is only this definition or declaration, which is probably not what you want
--
In file included from fs/namei.c:27:0:
>> include/linux/security.h:815:43: warning: 'struct nameidata_lookup' declared inside parameter list
struct nameidata_lookup *lookup, struct inode *inode)
^
>> include/linux/security.h:815:43: warning: its scope is only this definition or declaration, which is probably not what you want
fs/namei.c: In function 'restore_nameidata':
fs/namei.c:531:36: error: 'struct nameidata' has no member named 'lookup'
security_nameidata_put_lookup(&now->lookup, now->inode);
^
--
In file included from include/linux/lsm_hooks.h:28:0,
from security/commoncap.c:15:
>> include/linux/security.h:815:43: warning: 'struct nameidata_lookup' declared inside parameter list
struct nameidata_lookup *lookup, struct inode *inode)
^
>> include/linux/security.h:815:43: warning: its scope is only this definition or declaration, which is probably not what you want
In file included from security/commoncap.c:15:0:
>> include/linux/lsm_hooks.h:1522:13: warning: 'struct nameidata_lookup' declared inside parameter list
struct inode *inode);
^
vim +815 include/linux/security.h
813
814 static inline void security_nameidata_put_lookup(
> 815 struct nameidata_lookup *lookup, struct inode *inode)
816 { }
817
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
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
diff --git a/fs/namei.c b/fs/namei.c index 921ae32dbc80..d592b3fb0d1e 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -505,6 +505,9 @@ struct nameidata { struct inode *link_inode; unsigned root_seq; int dfd; +#ifdef CONFIG_SECURITY + struct nameidata_lookup lookup; +#endif } __randomize_layout; static void set_nameidata(struct nameidata *p, int dfd, struct filename *name) @@ -515,6 +518,9 @@ static void set_nameidata(struct nameidata *p, int dfd, struct filename *name) p->name = name; p->total_link_count = old ? old->total_link_count : 0; p->saved = old; +#ifdef CONFIG_SECURITY + p->lookup.security = NULL; +#endif current->nameidata = p; } @@ -522,6 +528,7 @@ static void restore_nameidata(void) { struct nameidata *now = current->nameidata, *old = now->saved; + security_nameidata_put_lookup(&now->lookup, now->inode); current->nameidata = old; if (old) old->total_link_count = now->total_link_count; @@ -549,6 +556,27 @@ static int __nd_alloc_stack(struct nameidata *nd) return 0; } +#ifdef CONFIG_SECURITY +/** + * current_nameidata_lookup - get the state of the current path walk + * + * @inode: inode associated to the path walk + * + * Used by LSM modules for access restriction based on path walk. The LSM is in + * charge of the lookup->security blob allocation and management. The hook + * security_nameidata_put_lookup() will be called after the path walk end. + * + * Return ERR_PTR(-ENOENT) if there is no match. + */ +struct nameidata_lookup *current_nameidata_lookup(const struct inode *inode) +{ + if (!current->nameidata || current->nameidata->inode != inode) + return ERR_PTR(-ENOENT); + return ¤t->nameidata->lookup; +} +EXPORT_SYMBOL(current_nameidata_lookup); +#endif + /** * path_connected - Verify that a path->dentry is below path->mnt.mnt_root * @path: nameidate to verify @@ -2009,6 +2037,13 @@ static inline u64 hash_name(const void *salt, const char *name) #endif +static inline void refresh_lookup(struct nameidata *nd) +{ +#ifdef CONFIG_SECURITY + nd->lookup.type = nd->last_type; +#endif +} + /* * Name resolution. * This is the basic name resolution function, turning a pathname into @@ -2025,6 +2060,8 @@ static int link_path_walk(const char *name, struct nameidata *nd) name++; if (!*name) return 0; + /* be ready for may_lookup() */ + refresh_lookup(nd); /* At this point we know we have a real path component. */ for(;;) { @@ -2064,6 +2101,8 @@ static int link_path_walk(const char *name, struct nameidata *nd) nd->last.hash_len = hash_len; nd->last.name = name; nd->last_type = type; + /* be ready for the next security_inode_permission() */ + refresh_lookup(nd); name += hashlen_len(hash_len); if (!*name) diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h index 7161d8e7ee79..d71cf183f0be 100644 --- a/include/linux/lsm_hooks.h +++ b/include/linux/lsm_hooks.h @@ -428,6 +428,10 @@ * security module does not know about attribute or a negative error code * to abort the copy up. Note that the caller is responsible for reading * and writing the xattrs as this hook is merely a filter. + * @nameidata_put_lookup: + * Deallocate and clear the current's nameidata->lookup.security field. + * @lookup->security contains the security structure to be freed. + * @inode is the last associated inode to the path walk * * Security hooks for file operations * @@ -1514,6 +1518,8 @@ union security_list_options { void (*inode_getsecid)(struct inode *inode, u32 *secid); int (*inode_copy_up)(struct dentry *src, struct cred **new); int (*inode_copy_up_xattr)(const char *name); + void (*nameidata_put_lookup)(struct nameidata_lookup *lookup, + struct inode *inode); int (*file_permission)(struct file *file, int mask); int (*file_alloc_security)(struct file *file); @@ -1805,6 +1811,7 @@ struct security_hook_heads { struct list_head inode_getsecid; struct list_head inode_copy_up; struct list_head inode_copy_up_xattr; + struct list_head nameidata_put_lookup; struct list_head file_permission; struct list_head file_alloc_security; struct list_head file_free_security; diff --git a/include/linux/namei.h b/include/linux/namei.h index a982bb7cd480..ba08cbb41f97 100644 --- a/include/linux/namei.h +++ b/include/linux/namei.h @@ -14,7 +14,19 @@ enum { MAX_NESTED_LINKS = 8 }; /* * Type of the last component on LOOKUP_PARENT */ -enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND}; +enum namei_type {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND}; + +#ifdef CONFIG_SECURITY +struct nameidata_lookup { + void *security; + enum namei_type type; +}; + +struct inode; + +extern struct nameidata_lookup *current_nameidata_lookup( + const struct inode *inode); +#endif /* * The bitmask for a lookup event: diff --git a/include/linux/security.h b/include/linux/security.h index 73f1ef625d40..b1fd4370daf8 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -31,6 +31,7 @@ #include <linux/string.h> #include <linux/mm.h> #include <linux/fs.h> +#include <linux/namei.h> struct linux_binprm; struct cred; @@ -302,6 +303,8 @@ int security_inode_listsecurity(struct inode *inode, char *buffer, size_t buffer void security_inode_getsecid(struct inode *inode, u32 *secid); int security_inode_copy_up(struct dentry *src, struct cred **new); int security_inode_copy_up_xattr(const char *name); +void security_nameidata_put_lookup(struct nameidata_lookup *lookup, + struct inode *inode); int security_file_permission(struct file *file, int mask); int security_file_alloc(struct file *file); void security_file_free(struct file *file); @@ -808,6 +811,10 @@ static inline int security_inode_copy_up_xattr(const char *name) return -EOPNOTSUPP; } +static inline void security_nameidata_put_lookup( + struct nameidata_lookup *lookup, struct inode *inode) +{ } + static inline int security_file_permission(struct file *file, int mask) { return 0; diff --git a/security/security.c b/security/security.c index 1cd8526cb0b7..17053c7a1a77 100644 --- a/security/security.c +++ b/security/security.c @@ -857,6 +857,13 @@ int security_inode_copy_up_xattr(const char *name) } EXPORT_SYMBOL(security_inode_copy_up_xattr); +void security_nameidata_put_lookup(struct nameidata_lookup *lookup, + struct inode *inode) +{ + call_void_hook(nameidata_put_lookup, lookup, inode); +} +EXPORT_SYMBOL(security_nameidata_put_lookup); + int security_file_permission(struct file *file, int mask) { int ret;
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. Signed-off-by: Mickaël Salaün <mic@digikod.net> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Casey Schaufler <casey@schaufler-ca.com> Cc: James Morris <jmorris@namei.org> Cc: John Johansen <john.johansen@canonical.com> Cc: Kees Cook <keescook@chromium.org> Cc: Paul Moore <paul@paul-moore.com> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: linux-fsdevel@vger.kernel.org --- fs/namei.c | 39 +++++++++++++++++++++++++++++++++++++++ include/linux/lsm_hooks.h | 7 +++++++ include/linux/namei.h | 14 +++++++++++++- include/linux/security.h | 7 +++++++ security/security.c | 7 +++++++ 5 files changed, 73 insertions(+), 1 deletion(-)