On Tue, Jun 8, 2021 at 7:02 AM Ondrej Mosnacek wrote:
> On Thu, Jun 3, 2021 at 7:46 PM Paul Moore wrote:
...
> > It sounds an awful lot like the lockdown hook is in the wrong spot.
> > It sounds like it would be a lot better to relocate the hook than
> > remove it.
>
> I don't see how you would
On Thu, Jun 3, 2021 at 7:46 PM Paul Moore wrote:
> On Wed, Jun 2, 2021 at 9:40 AM Ondrej Mosnacek wrote:
> > On Fri, May 28, 2021 at 3:37 AM Paul Moore wrote:
[...]
> > > I know you and Casey went back and forth on this in v1, but I agree
> > > with Casey that having two LSM hooks here is a mist
On Sat, Jun 5, 2021 at 2:17 PM Linus Torvalds
wrote:
> On Sat, Jun 5, 2021 at 11:11 AM Casey Schaufler
> wrote:
> >
> > You have fallen into a common fallacy. The fact that the "code runs"
> > does not assure that the "system works right". In the security world
> > we face this all the time, oft
On Fri, Jun 4, 2021 at 8:08 PM Alexei Starovoitov
wrote:
> On Fri, Jun 4, 2021 at 4:34 PM Paul Moore wrote:
> >
> > > Again, the problem is not limited to BPF at all. kprobes is doing
> > > register-
> > > time hooks which are equivalent to the one of BPF. Anything in run-time
> > > trying to pr
On Sat, Jun 5, 2021 at 11:11 AM Casey Schaufler wrote:
>
> You have fallen into a common fallacy. The fact that the "code runs"
> does not assure that the "system works right". In the security world
> we face this all the time, often with performance expectations. In this
> case the BPF design has
On 6/4/2021 5:08 PM, Alexei Starovoitov wrote:
> On Fri, Jun 4, 2021 at 4:34 PM Paul Moore wrote:
>>> Again, the problem is not limited to BPF at all. kprobes is doing register-
>>> the hooks which are equivalent to the one of BPF. Anything in run-time
>>> trying to prevent probe_read_kernel by kp
On Fri, Jun 4, 2021 at 4:34 PM Paul Moore wrote:
>
> > Again, the problem is not limited to BPF at all. kprobes is doing register-
> > time hooks which are equivalent to the one of BPF. Anything in run-time
> > trying to prevent probe_read_kernel by kprobes or BPF is broken by design.
>
> Not bein
On Fri, Jun 4, 2021 at 2:02 PM Daniel Borkmann wrote:
>
> On 6/4/21 6:50 AM, Paul Moore wrote:
> > On Thu, Jun 3, 2021 at 2:53 PM Daniel Borkmann wrote:
> [...]
> >> I did run this entire discussion by both of the other BPF co-maintainers
> >> (Alexei, Andrii, CC'ed) and together we did further b
On 6/4/21 6:50 AM, Paul Moore wrote:
On Thu, Jun 3, 2021 at 2:53 PM Daniel Borkmann wrote:
[...]
I did run this entire discussion by both of the other BPF co-maintainers
(Alexei, Andrii, CC'ed) and together we did further brainstorming on the
matter on how we could solve this, but couldn't fin
On Thu, Jun 3, 2021 at 2:53 PM Daniel Borkmann wrote:
> On 6/2/21 5:13 PM, Paul Moore wrote:
> [...]
> > Help me out here, is your answer that the access check can only be
> > done at BPF program load time? That isn't really a solution from a
> > SELinux perspective as far as I'm concerned.
>
> T
On 6/2/21 5:13 PM, Paul Moore wrote:
[...]
Help me out here, is your answer that the access check can only be
done at BPF program load time? That isn't really a solution from a
SELinux perspective as far as I'm concerned.
That is the current answer. The unfortunate irony is that 59438b46471a
(
On Wed, Jun 2, 2021 at 9:40 AM Ondrej Mosnacek wrote:
> On Fri, May 28, 2021 at 3:37 AM Paul Moore wrote:
> > On Mon, May 17, 2021 at 5:22 AM Ondrej Mosnacek wrote:
> > >
> > > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> > > lockdown") added an implementation of the lock
On Wed, Jun 2, 2021 at 8:40 AM Daniel Borkmann wrote:
> On 6/1/21 10:47 PM, Paul Moore wrote:
> > The thing I'm worried about would be the case where a LSM policy
> > change requires that an existing BPF program be removed or disabled.
> > I'm guessing based on the refcounting that there is not pr
On Fri, May 28, 2021 at 3:37 AM Paul Moore wrote:
> On Mon, May 17, 2021 at 5:22 AM Ondrej Mosnacek wrote:
> >
> > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> > lockdown") added an implementation of the locked_down LSM hook to
> > SELinux, with the aim to restrict which d
On 6/1/21 10:47 PM, Paul Moore wrote:
On Mon, May 31, 2021 at 4:24 AM Daniel Borkmann wrote:
On 5/29/21 8:48 PM, Paul Moore wrote:
[...]
Daniel's patch side steps that worry by just doing the lockdown
permission check when the BPF program is loaded, but that isn't a
great solution if the polic
On Mon, May 31, 2021 at 4:24 AM Daniel Borkmann wrote:
> On 5/29/21 8:48 PM, Paul Moore wrote:
> [...]
> > Daniel's patch side steps that worry by just doing the lockdown
> > permission check when the BPF program is loaded, but that isn't a
> > great solution if the policy changes afterward. I wa
On 5/29/21 8:48 PM, Paul Moore wrote:
[...]
Daniel's patch side steps that worry by just doing the lockdown
permission check when the BPF program is loaded, but that isn't a
great solution if the policy changes afterward. I was hoping there
might be some way to perform the permission check as ne
On Fri, May 28, 2021 at 2:28 PM Daniel Borkmann wrote:
> In the case of tracing, it's different. You install small programs that are
> triggered when certain events fire. Random example from bpftrace's README [0],
> you want to generate a histogram of syscall counts by program. One-liner is:
>
>
On Fri, May 28, 2021 at 2:28 PM Daniel Borkmann wrote:
> On 5/28/21 5:47 PM, Paul Moore wrote:
> > Let's reset.
>
> Sure, yep, lets shortly take one step back. :)
>
> > What task_struct is running the BPF tracing program which is calling
> > into security_locked_down()? My current feeling is that
On 5/28/21 5:47 PM, Paul Moore wrote:
On Fri, May 28, 2021 at 3:10 AM Daniel Borkmann wrote:
On 5/28/21 3:37 AM, Paul Moore wrote:
On Mon, May 17, 2021 at 5:22 AM Ondrej Mosnacek wrote:
Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
lockdown") added an implementation of
On Fri, May 28, 2021 at 10:43 AM Daniel Borkmann wrote:
> On 5/28/21 3:42 PM, Ondrej Mosnacek wrote:
> > (I'm off work today and plan to reply also to Paul's comments next
> > week, but for now let me at least share a couple quick thoughts on
> > Daniel's patch.)
Oooh, I sense some disagreement b
On Fri, May 28, 2021 at 3:10 AM Daniel Borkmann wrote:
> On 5/28/21 3:37 AM, Paul Moore wrote:
> > On Mon, May 17, 2021 at 5:22 AM Ondrej Mosnacek wrote:
> >>
> >> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> >> lockdown") added an implementation of the locked_down LSM hoo
On 5/28/21 3:42 PM, Ondrej Mosnacek wrote:
(I'm off work today and plan to reply also to Paul's comments next
week, but for now let me at least share a couple quick thoughts on
Daniel's patch.)
On Fri, May 28, 2021 at 11:56 AM Daniel Borkmann wrote:
On 5/28/21 9:09 AM, Daniel Borkmann wrote:
On Mon, 17 May 2021 11:20:06 +0200
Ondrej Mosnacek wrote:
> diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
> index 1261e8b41edb..7edde3fc22f5 100644
> --- a/fs/tracefs/inode.c
> +++ b/fs/tracefs/inode.c
> @@ -396,7 +396,7 @@ struct dentry *tracefs_create_file(const char *name,
> umode_t mo
(I'm off work today and plan to reply also to Paul's comments next
week, but for now let me at least share a couple quick thoughts on
Daniel's patch.)
On Fri, May 28, 2021 at 11:56 AM Daniel Borkmann wrote:
>
> On 5/28/21 9:09 AM, Daniel Borkmann wrote:
> > On 5/28/21 3:37 AM, Paul Moore wrote:
>
On 5/28/21 1:47 PM, Jiri Olsa wrote:
On Fri, May 28, 2021 at 11:56:02AM +0200, Daniel Borkmann wrote:
Ondrej / Paul / Jiri: at least for the BPF tracing case specifically (I haven't
looked
at the rest but it's also kind of independent), the attached fix should address
both
reported issues, pl
On Fri, May 28, 2021 at 11:56:02AM +0200, Daniel Borkmann wrote:
SNIP
> Ondrej / Paul / Jiri: at least for the BPF tracing case specifically (I
> haven't looked
> at the rest but it's also kind of independent), the attached fix should
> address both
> reported issues, please take a look & test.
On Fri, May 28, 2021 at 11:56:02AM +0200, Daniel Borkmann wrote:
SNIP
>
> Ondrej / Paul / Jiri: at least for the BPF tracing case specifically (I
> haven't looked
> at the rest but it's also kind of independent), the attached fix should
> address both
> reported issues, please take a look & te
On 5/28/21 9:09 AM, Daniel Borkmann wrote:
On 5/28/21 3:37 AM, Paul Moore wrote:
On Mon, May 17, 2021 at 5:22 AM Ondrej Mosnacek wrote:
Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
lockdown") added an implementation of the locked_down LSM hook to
SELinux, with the aim to
On Fri, May 28, 2021 at 09:09:57AM +0200, Daniel Borkmann wrote:
> On 5/28/21 3:37 AM, Paul Moore wrote:
> > On Mon, May 17, 2021 at 5:22 AM Ondrej Mosnacek wrote:
> > >
> > > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> > > lockdown") added an implementation of the locked
On 5/28/21 3:37 AM, Paul Moore wrote:
On Mon, May 17, 2021 at 5:22 AM Ondrej Mosnacek wrote:
Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
lockdown") added an implementation of the locked_down LSM hook to
SELinux, with the aim to restrict which domains are allowed to perfo
On Mon, May 17, 2021 at 5:22 AM Ondrej Mosnacek wrote:
>
> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> lockdown") added an implementation of the locked_down LSM hook to
> SELinux, with the aim to restrict which domains are allowed to perform
> operations that would breach
On Thu, May 27, 2021 at 12:33 AM James Morris wrote:
> On Wed, 26 May 2021, Ondrej Mosnacek wrote:
>
> > Thanks, Michael!
> >
> > James/Paul, is there anything blocking this patch from being merged?
> > Especially the BPF case is causing real trouble for people and the
> > only workaround is to br
On Wed, 26 May 2021, Ondrej Mosnacek wrote:
> Thanks, Michael!
>
> James/Paul, is there anything blocking this patch from being merged?
> Especially the BPF case is causing real trouble for people and the
> only workaround is to broadly allow lockdown::confidentiality in the
> policy.
It would b
On Mon, May 17, 2021 at 1:00 PM Michael Ellerman wrote:
> Ondrej Mosnacek writes:
> > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> > lockdown") added an implementation of the locked_down LSM hook to
> > SELinux, with the aim to restrict which domains are allowed to perform
Ondrej Mosnacek writes:
> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> lockdown") added an implementation of the locked_down LSM hook to
> SELinux, with the aim to restrict which domains are allowed to perform
> operations that would breach lockdown.
>
> However, in several
Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
lockdown") added an implementation of the locked_down LSM hook to
SELinux, with the aim to restrict which domains are allowed to perform
operations that would breach lockdown.
However, in several places the security_locked_down() h
37 matches
Mail list logo
