[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170824025030.sxl2hkpcbzipb47y@ast-mbp>
Date: Wed, 23 Aug 2017 19:50:32 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Mickaël Salaün <mic@...ikod.net>
Cc: linux-kernel@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>,
Andy Lutomirski <luto@...capital.net>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Casey Schaufler <casey@...aufler-ca.com>,
Daniel Borkmann <daniel@...earbox.net>,
David Drysdale <drysdale@...gle.com>,
"David S . Miller" <davem@...emloft.net>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
James Morris <james.l.morris@...cle.com>,
Jann Horn <jann@...jh.net>, Jonathan Corbet <corbet@....net>,
Matthew Garrett <mjg59@...f.ucam.org>,
Michael Kerrisk <mtk.manpages@...il.com>,
Kees Cook <keescook@...omium.org>, Paul Moore <paul@...l-moore.com>,
Sargun Dhillon <sargun@...gun.me>,
"Serge E . Hallyn" <serge@...lyn.com>,
Shuah Khan <shuah@...nel.org>, Tejun Heo <tj@...nel.org>,
Thomas Graf <tgraf@...g.ch>, Will Drewry <wad@...omium.org>,
kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org,
linux-security-module@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v7 05/10] landlock: Add LSM hooks related to
filesystem
On Mon, Aug 21, 2017 at 02:09:28AM +0200, Mickaël Salaün wrote:
> Handle 33 filesystem-related LSM hooks for the Landlock filesystem
> event: LANDLOCK_SUBTYPE_EVENT_FS.
>
> A Landlock event wrap LSM hooks for similar kernel object types (e.g.
> struct file, struct path...). Multiple LSM hooks can trigger the same
> Landlock event.
>
> Landlock handle nine coarse-grained actions: read, write, execute, new,
> get, remove, ioctl, lock and fcntl. Each of them abstract LSM hook
> access control in a way that can be extended in the future.
>
> The Landlock LSM hook registration is done after other LSM to only run
> actions from user-space, via eBPF programs, if the access was granted by
> major (privileged) LSMs.
>
> Signed-off-by: Mickaël Salaün <mic@...ikod.net>
...
> +/* WRAP_ARG_SB */
> +#define WRAP_ARG_SB_TYPE WRAP_TYPE_FS
> +#define WRAP_ARG_SB_DEC(arg) \
> + EXPAND_C(WRAP_TYPE_FS) wrap_##arg = \
> + { .type = BPF_HANDLE_FS_TYPE_DENTRY, .dentry = arg->s_root };
> +#define WRAP_ARG_SB_VAL(arg) ((uintptr_t)&wrap_##arg)
> +#define WRAP_ARG_SB_OK(arg) (arg && arg->s_root)
...
> +HOOK_NEW_FS(sb_remount, 2,
> + struct super_block *, sb,
> + void *, data,
> + WRAP_ARG_SB, sb,
> + WRAP_ARG_RAW, LANDLOCK_ACTION_FS_WRITE
> +);
this looks wrong. casting super_block to dentry?
> +/* a directory inode contains only one dentry */
> +HOOK_NEW_FS(inode_create, 3,
> + struct inode *, dir,
> + struct dentry *, dentry,
> + umode_t, mode,
> + WRAP_ARG_INODE, dir,
> + WRAP_ARG_RAW, LANDLOCK_ACTION_FS_WRITE
> +);
more general question: why you're not wrapping all useful
arguments? Like in the above dentry can be acted upon
by the landlock rule and it's readily available...
The limitation of only 2 args looks odd.
Is it a hard limitation ? how hard to extend?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
