netdev - Re: [RFC 0/3] bpf: Add d

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] [day] [month] [year] [list]

Message-ID: <20200407094556.GC3144092@krava>
Date:   Tue, 7 Apr 2020 11:45:56 +0200
From:   Jiri Olsa <jolsa@...hat.com>
To:     KP Singh <kpsingh@...omium.org>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Jiri Olsa <jolsa@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, Yonghong Song <yhs@...com>,
        Martin KaFai Lau <kafai@...com>,
        David Miller <davem@...hat.com>,
        John Fastabend <john.fastabend@...il.com>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        Wenbo Zhang <ethercflow@...il.com>,
        Andrii Nakryiko <andriin@...com>, bgregg@...flix.com
Subject: Re: [RFC 0/3] bpf: Add d_path helper

On Tue, Apr 07, 2020 at 11:27:53AM +0200, KP Singh wrote:
> On 06-Apr 18:10, Alexei Starovoitov wrote:
> > On Mon, Apr 06, 2020 at 11:09:18AM +0200, Jiri Olsa wrote:
> > > 
> > > is there any way we could have d_path functionality (even
> > > reduced and not working for all cases) that could be used
> > > or called like that?
> > 
> > I agree with Al. This helper cannot be enabled for all of bpf tracing.
> > We have to white list its usage for specific callsites only.
> > May be all of lsm hooks are safe. I don't know yet. This has to be
> > analyzed carefully. Every hook. One by one.
> 
> I agree with this, there are some LSM hooks which do get called in
> interrupt context, eg. task_free (which gets called in an RCU
> callback).
> 
> The hooks that we are using it for and we know that it works (using
> our experimental helpers similar to this) are the bprm_* hooks in the
> exec pathway (for logic based on the path of the executable).
> 
> It might be worth whitelisting these functions by adding verifier ops
> for LSM programs?
> 
> Would you want to do it as a part of this series?

I guess we should to do some generic whitelist solution that
would be usable by any prog type.. I'll try to put something
together

jirka