From: KP Singh <kpsingh@chromium.org> To: "Mickaël Salaün" <mic@digikod.net> Cc: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>, linux-kernel@vger.kernel.org, "Alexei Starovoitov" <ast@kernel.org>, "Andy Lutomirski" <luto@amacapital.net>, "Casey Schaufler" <casey@schaufler-ca.com>, "Daniel Borkmann" <daniel@iogearbox.net>, "David Drysdale" <drysdale@google.com>, "Florent Revest" <revest@chromium.org>, "James Morris" <jmorris@namei.org>, "Jann Horn" <jann@thejh.net>, "John Johansen" <john.johansen@canonical.com>, "Jonathan Corbet" <corbet@lwn.net>, "Kees Cook" <keescook@chromium.org>, "Michael Kerrisk" <mtk.manpages@gmail.com>, "Mickaël Salaün" <mickael.salaun@ssi.gouv.fr>, "Paul Moore" <paul@paul-moore.com>, "Sargun Dhillon" <sargun@sargun.me>, "Serge E . Hallyn" <serge@hallyn.com>, "Shuah Khan" <shuah@kernel.org>, "Stephen Smalley" <sds@tycho.nsa.gov>, "Tejun Heo" <tj@kernel.org>, "Tetsuo Handa" <penguin-kernel@I-love.SAKURA.ne.jp>, "Tycho Andersen" <tycho@tycho.ws>, "Will Drewry" <wad@chromium.org>, bpf@vger.kernel.org, kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH bpf-next v13 4/7] landlock: Add ptrace LSM hooks Date: Wed, 6 Nov 2019 15:45:58 +0530 Message-ID: <20191106101558.GA19467@chromium.org> (raw) In-Reply-To: <23acf523-dbc4-855b-ca49-2bbfa5e7117e@digikod.net> On 05-Nov 19:01, Mickaël Salaün wrote: > > On 05/11/2019 18:18, Alexei Starovoitov wrote: > > On Mon, Nov 04, 2019 at 06:21:43PM +0100, Mickaël Salaün wrote: > >> Add a first Landlock hook that can be used to enforce a security policy > >> or to audit some process activities. For a sandboxing use-case, it is > >> needed to inform the kernel if a task can legitimately debug another. > >> ptrace(2) can also be used by an attacker to impersonate another task > >> and remain undetected while performing malicious activities. > >> > >> Using ptrace(2) and related features on a target process can lead to a > >> privilege escalation. A sandboxed task must then be able to tell the > >> kernel if another task is more privileged, via ptrace_may_access(). > >> > >> Signed-off-by: Mickaël Salaün <mic@digikod.net> > > ... > >> +static int check_ptrace(struct landlock_domain *domain, > >> + struct task_struct *tracer, struct task_struct *tracee) > >> +{ > >> + struct landlock_hook_ctx_ptrace ctx_ptrace = { > >> + .prog_ctx = { > >> + .tracer = (uintptr_t)tracer, > >> + .tracee = (uintptr_t)tracee, > >> + }, > >> + }; > > > > So you're passing two kernel pointers obfuscated as u64 into bpf program > > yet claiming that the end goal is to make landlock unprivileged?! > > The most basic security hole in the tool that is aiming to provide security. > > How could you used these pointers without dedicated BPF helpers? This > context items are typed as PTR_TO_TASK and can't be used without a > dedicated helper able to deal with ARG_PTR_TO_TASK. Moreover, pointer > arithmetic is explicitly forbidden (and I added tests for that). Did I > miss something? > > > > > I think the only way bpf-based LSM can land is both landlock and KRSI > > developers work together on a design that solves all use cases. > > As I said in a previous cover letter [1], that would be great. I think > that the current Landlock bases (almost everything from this series > except the seccomp interface) should meet both needs, but I would like > to have the point of view of the KRSI developers. As I mentioned we are willing to collaborate but the current landlock patches does not meet the needs for KRSI: * One program type per use-case (eg. LANDLOCK_PROG_PTRACE) as opposed to a single program type. This is something that KRSI proposed in it's initial design [1] and the new common "eBPF + LSM" based approach [2] would maintain as well. * Landlock chooses to have multiple LSM hooks per landlock hook which is more restrictive. It's not easy to write precise MAC and Audit policies for a privileged LSM based on this and this ends up bloating the context that needs to be maintained and requires avoidable boilerplate work in the kernel. [1] https://lore.kernel.org/patchwork/project/lkml/list/?series=410101 [2] https://lore.kernel.org/bpf/20191106100655.GA18815@chromium.org/T/#u - KP Singh > > [1] https://lore.kernel.org/lkml/20191029171505.6650-1-mic@digikod.net/ > > > BPF is capable > > to be a superset of all existing LSMs whereas landlock and KRSI propsals today > > are custom solutions to specific security concerns. BPF subsystem was extended > > with custom things in the past. In networking we have lwt, skb, tc, xdp, sk > > program types with a lot of overlapping functionality. We couldn't figure out > > how to generalize them into single 'networking' program. Now we can and we > > should. Accepting two partially overlapping bpf-based LSMs would be repeating > > the same mistake again. > > I'll let the LSM maintainers comment on whether BPF could be a superset > of all LSM, but given the complexity of an access-control system, I have > some doubts though. Anyway, we need to start somewhere and then iterate. > This patch series is a first step.
next prev parent reply index Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-04 17:21 [PATCH bpf-next v13 0/7] Landlock LSM Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 1/7] bpf,landlock: Define an eBPF program type for Landlock hooks Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 2/7] landlock: Add the management of domains Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 3/7] landlock,seccomp: Apply Landlock programs to process hierarchy Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 4/7] landlock: Add ptrace LSM hooks Mickaël Salaün 2019-11-05 17:18 ` Alexei Starovoitov 2019-11-05 17:55 ` Casey Schaufler 2019-11-05 19:31 ` Alexei Starovoitov 2019-11-05 19:55 ` Casey Schaufler 2019-11-05 21:54 ` Alexei Starovoitov 2019-11-05 22:32 ` Casey Schaufler 2019-11-05 18:01 ` Mickaël Salaün 2019-11-05 19:34 ` Alexei Starovoitov 2019-11-05 22:18 ` Mickaël Salaün 2019-11-06 10:06 ` KP Singh 2019-11-06 16:55 ` Mickaël Salaün 2019-11-06 21:45 ` KP Singh 2019-11-08 14:08 ` Mickaël Salaün 2019-11-08 14:34 ` Daniel Borkmann 2019-11-08 15:39 ` Mickaël Salaün 2019-11-08 15:27 ` KP Singh 2019-11-06 10:15 ` KP Singh [this message] 2019-11-06 16:58 ` Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 5/7] bpf,landlock: Add task_landlock_ptrace_ancestor() helper Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 6/7] bpf,landlock: Add tests for the Landlock ptrace program type Mickaël Salaün 2019-11-04 17:21 ` [PATCH bpf-next v13 7/7] landlock: Add user and kernel documentation for Landlock Mickaël Salaün
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191106101558.GA19467@chromium.org \ --to=kpsingh@chromium.org \ --cc=alexei.starovoitov@gmail.com \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=casey@schaufler-ca.com \ --cc=corbet@lwn.net \ --cc=daniel@iogearbox.net \ --cc=drysdale@google.com \ --cc=jann@thejh.net \ --cc=jmorris@namei.org \ --cc=john.johansen@canonical.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mic@digikod.net \ --cc=mickael.salaun@ssi.gouv.fr \ --cc=mtk.manpages@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=paul@paul-moore.com \ --cc=penguin-kernel@I-love.SAKURA.ne.jp \ --cc=revest@chromium.org \ --cc=sargun@sargun.me \ --cc=sds@tycho.nsa.gov \ --cc=serge@hallyn.com \ --cc=shuah@kernel.org \ --cc=tj@kernel.org \ --cc=tycho@tycho.ws \ --cc=wad@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Kernel-hardening Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/kernel-hardening/0 kernel-hardening/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 kernel-hardening kernel-hardening/ https://lore.kernel.org/kernel-hardening \ kernel-hardening@lists.openwall.com public-inbox-index kernel-hardening Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/com.openwall.lists.kernel-hardening AGPL code for this site: git clone https://public-inbox.org/public-inbox.git