On Fri, Dec 15, 2023 at 6:07 AM David Gstir wrote:
>
> This is a revival of the previous patch set submitted by Richard Weinberger:
> https://lore.kernel.org/linux-integrity/20210614201620.30451-1-rich...@nod.at/
>
> v4 is here:
> https://lore.kernel.org/keyrings/20231024162024.51260-1-da...@sigma
On Tue, Aug 1, 2023 at 9:24 AM Ondrej Mosnacek wrote:
> On Fri, Jul 28, 2023 at 5:12 PM Paul Moore wrote:
> >
> > On Fri, Jul 28, 2023 at 9:24 AM Christian Göttsche
> > wrote:
> > >
> > > On Fri, 28 Jul 2023 at 15:14, Ondrej Mosnacek wrote:
> >
On Fri, Jul 28, 2023 at 9:24 AM Christian Göttsche
wrote:
>
> On Fri, 28 Jul 2023 at 15:14, Ondrej Mosnacek wrote:
> >
> > On Fri, Jul 28, 2023 at 1:52 PM Stephen Smalley
> > wrote:
> > >
> > > On Fri, Jul 28, 2023 at 7:36 AM Ondrej Mosnacek
> > > wrote:
> > > >
> > > > On Fri, Jul 28, 2023 at
On Tue, Jul 18, 2023 at 7:48 PM Sean Christopherson wrote:
>
> Signed-off-by: Sean Christopherson
> ---
> security/security.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Paul Moore
> diff --git a/security/security.c b/security/security.c
> index b720424ca37d
On Wed, May 17, 2023 at 10:51 AM Arnd Bergmann wrote:
> On Wed, May 17, 2023, at 16:33, Paul Moore wrote:
> > On May 17, 2023 Arnd Bergmann wrote:
>
> > We probably should move the audit_serial() and auditsc_get_stamp()
> > away from the watch/mark/tree functions, but
On May 17, 2023 Arnd Bergmann wrote:
>
> Building with 'make W=1' reveals two function definitions without
> a previous prototype in the audit code:
>
> lib/compat_audit.c:32:5: error: no previous prototype for
> 'audit_classify_compat_syscall' [-Werror=missing-prototypes]
> kernel/audit.c:1813
| 1 +
> 3 files changed, 26 insertions(+), 1 deletion(-)
The lockdown changes are trivial, but they look fine to me.
Acked-by: Paul Moore (LSM)
--
paul-moore.com
gt; ---
> arch/powerpc/platforms/pseries/reconfig.c | 5 +
> include/linux/security.h | 1 +
> security/security.c | 1 +
> 3 files changed, 7 insertions(+)
Thanks for moving the definitions.
Acked-by: Paul Moore (LSM)
> diff --git a/
On Fri, Sep 23, 2022 at 11:40 AM Nathan Lynch wrote:
> Michael Ellerman writes:
> > Paul Moore writes:
> >> On Thu, Sep 22, 2022 at 3:38 PM Nathan Lynch wrote:
> >>>
> >>> The error injection facility on pseries VMs allows corruption of
> >&
On Thu, Sep 22, 2022 at 3:38 PM Nathan Lynch wrote:
>
> The error injection facility on pseries VMs allows corruption of
> arbitrary guest memory, potentially enabling a sufficiently privileged
> user to disable lockdown or perform other modifications of the running
> kernel via the rtas syscall.
On Thu, Sep 22, 2022 at 3:38 PM Nathan Lynch wrote:
>
> The /proc/powerpc/ofdt interface allows the root user to freely alter
> the in-kernel device tree, enabling arbitrary physical address writes
> via drivers that could bind to malicious device nodes, thus making it
> possible to disable lockdo
On Fri, Dec 17, 2021 at 9:11 AM Christophe Leroy
wrote:
> Le 17/12/2021 à 00:04, Paul Moore a écrit :
> > On Thu, Dec 16, 2021 at 4:08 AM Christophe Leroy
> > wrote:
> >> Thanks Cédric, I've now been able to install debian PPC32 port of DEBIAN
> >> 11
that let us know.
> # Test 3 got: "256" (backlog_wait_time_actual_reset/test at line 151)
> # Expected: "0"
> # backlog_wait_time_actual_reset/test line 151 is: ok( $result, 0 );
> # Was an event found?
...
--
paul moore
www.paul-moore.com
t some
point you/someone was able to run the test suite, why isn't that
working now? Or was it a different powerpc ABI?
--
paul moore
www.paul-moore.com
ranch" would be helpful. Although I guess that would
require either the revert having the right metadata, e.g. "Cc:", or
that prior mentioned logic to find the original commit so the proper
To/CC lines could be generated.
--
paul moore
www.paul-moore.com
On Tue, Nov 2, 2021 at 7:19 PM Michael Ellerman wrote:
> Paul Moore writes:
> > On Tue, Nov 2, 2021 at 7:38 AM Michael Ellerman
> > wrote:
> >>
> >> On Tue, 24 Aug 2021 13:36:13 + (UTC), Christophe Leroy wrote:
> >> > Commit e65e1fc2d24b
t: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
>
> https://git.kernel.org/powerpc/c/566af8cda399c088763d07464463dc871c943b54
Did the test failure discussed earlier in this thread ever get
resolved? If not, this really shouldn't be in linux-next IMO.
--
paul moore
www.paul-moore.com
On Wed, Oct 27, 2021 at 7:41 AM Christophe Leroy
wrote:
> Le 27/10/2021 à 13:29, Michael Ellerman a écrit :
> > Paul Moore writes:
> >> On Tue, Oct 26, 2021 at 6:55 AM Michael Ellerman
> >> wrote:
> >>> Stephen Rothwell writes:
> >>>>
t;
> If I don't hear anything I'll leave it as-is.
Hi Michael,
Last I recall from the powerpc/audit thread there were still some
issues with audit working properly in your testing, has that been
resolved? If nothing else, -rc7 seems a bit late for this to hit
-next for me to feel comfortable about this.
--
paul moore
www.paul-moore.com
On Wed, Sep 15, 2021 at 10:59 PM Paul Moore wrote:
>
> On Mon, Sep 13, 2021 at 5:05 PM Paul Moore wrote:
> >
> > On Mon, Sep 13, 2021 at 10:02 AM Ondrej Mosnacek
> > wrote:
> > >
> > > Commit 59438b46471a ("security,lockdown,selinux: implement S
On Mon, Sep 13, 2021 at 5:05 PM Paul Moore wrote:
>
> On Mon, Sep 13, 2021 at 10:02 AM Ondrej Mosnacek wrote:
> >
> > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> > lockdown") added an implementation of the locked_down LSM hook to
>
eep using the current task's
> context in the a) case, since the eventual data leak can be
> circumvented anyway via b), plus there is no way for the task to
> indicate that it doesn't care about the actual key value, so the
> check could generate a lot of &q
On Tue, Aug 31, 2021 at 2:58 PM Dan Williams wrote:
> On Tue, Aug 31, 2021 at 6:53 AM Paul Moore wrote:
> > On Tue, Aug 31, 2021 at 5:09 AM Ondrej Mosnacek wrote:
> > > On Sat, Jun 19, 2021 at 12:18 AM Dan Williams
> > > wrote:
> > > > On Wed,
have known bugs in them. Yes, this is a pre-existing
condition, but it seems well within the scope of this work to address
it as well.
This isn't something that is going to get merged while the merge
window is open, so at the very least you've got almost two weeks to
sort this out - please do that.
--
paul moore
www.paul-moore.com
On Tue, Aug 31, 2021 at 5:08 AM Ondrej Mosnacek wrote:
> Can we move this forward somehow, please?
As mentioned previously, I can merge this via the SELinux tree but I
need to see some ACKs from the other subsystems first, not to mention
some resolution to the outstanding questions.
--
p
On Thu, Aug 26, 2021 at 10:37 AM Michael Ellerman wrote:
> Paul Moore writes:
> > On Tue, Aug 24, 2021 at 1:11 PM Christophe Leroy
> > wrote:
> >> Le 24/08/2021 à 16:47, Paul Moore a écrit :
> >> > On Tue, Aug 24, 2021 at 9:36 AM Christophe Leroy
&
On Tue, Aug 24, 2021 at 1:11 PM Christophe Leroy
wrote:
> Le 24/08/2021 à 16:47, Paul Moore a écrit :
> > On Tue, Aug 24, 2021 at 9:36 AM Christophe Leroy
> > wrote:
> >>
> >> Commit e65e1fc2d24b ("[PATCH] syscall class hookup for all normal
> >>
it: Add generic compat syscall support")
> added generic support for bi-arch.
>
> Convert powerpc to that bi-arch generic audit support.
>
> Cc: Paul Moore
> Cc: Eric Paris
> Signed-off-by: Christophe Leroy
> ---
> Resending v2 with Audit people in Cc
>
> v2:
g if we want to
add to it in the future. What do you think about something like
"audit_arch.h" instead?
If that change is okay with you I can go ahead and do the rename while
I'm merging the patches, I'll consider it penance for letting this
patchset sit for so long :/
--
paul moore
www.paul-moore.com
ntial, can I just use "no_cred"? My
thinking with the single, always-pass-a-cred function is that callers
don't have to worry about choosing from multiple, similar hooks and
they know they need to pass a cred which hopefully gets them thinking
about what cred is appropriate. It's not foolproof, but I believe the
single hook approach will be less prone to accidents ... or so I hope
:)
--
paul moore
www.paul-moore.com
eep using the current task's
> context in the a) case, since the eventual data leak can be
> circumvented anyway via b), plus there is no way for the task to
> indicate that it doesn't care about the actual key value, so the
> check could generate a lot of &q
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.
&g
we saw that in this thread, but
that's to be expected anytime you have competing priorities. The
important part is that eventually we figure out some way to move
forward, and the fact that we are still all making progress and
putting out new kernel releases is proof that we are finding a way.
That's what matters to me, and if I was forced to guess, I would
imagine that matters quite a lot to most of us here.
--
paul moore
www.paul-moore.com
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.
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, C
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 perspe
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
> > >
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 th
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 i
ither lock_kernel_down() or lockdown_write() might want to do a
call_blocking_lsm_notifier(LSM_POLICY_CHANGE, NULL) call.
--
paul moore
www.paul-moore.com
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_lo
h.)
Oooh, I sense some disagreement brewing :)
> > 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 Mon, May 17, 2021 at 5:22 AM O
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")
| 3 ++-
> include/linux/lsm_hooks.h | 3 ++-
> include/linux/security.h | 11 ---
> kernel/trace/bpf_trace.c | 4 ++--
> net/xfrm/xfrm_user.c | 2 +-
> security/lockdown/lockdown.c | 5 +++--
> security/security.c | 6 +++---
> security/selinux/hooks.c | 12 +---
> 10 files changed, 33 insertions(+), 19 deletions(-)
--
paul moore
www.paul-moore.com
I looked at the v1 posting but haven't had a chance yet to look at v2;
I promise to get to it today, but it might not happen until later
tonight.
> Let's see if anyone else can look at this in the next couple of days.
--
paul moore
www.paul-moore.com
casting and masking all at once. Maybe a
> small static inline helper would be good for the sake of legibility? Sm
> like:
>
> static inline u32 audit_openat2_acc(struct open_how *how, int mask)
> {
> u32 flags = how->flags;
> return mask & ACC_MODE(flags);
> }
>
> but not sure. Just seems more legible to me.
> Otherwise.
I'm on the fence about this. I understand Christian's concern, but I
have a bit of hatred towards single caller functions like this. Since
this function isn't really high-touch, and I don't expect that to
change in the near future, let's leave the casting mess as-is.
--
paul moore
www.paul-moore.com
On Tue, May 11, 2021 at 1:14 PM Richard Guy Briggs wrote:
>
> On 2021-05-10 21:23, Paul Moore wrote:
> > On Fri, Apr 30, 2021 at 4:36 PM Richard Guy Briggs wrote:
> > >
> > > Replace audit syscall class magic numbers with macros.
> > >
> > > This
TSCM_H_
> +
> +enum auditsc_class_t {
> + AUDITSC_NATIVE = 0,
> + AUDITSC_COMPAT,
> + AUDITSC_OPEN,
> + AUDITSC_OPENAT,
> + AUDITSC_SOCKETCALL,
> + AUDITSC_EXECVE,
> +
> + AUDITSC_NVALS /* count */
> +};
> +
> +#endif
--
paul moore
www.paul-moore.com
3 ("syscall_get_arch: remove useless function arguments")
> Reverts: 1002d94d3076 ("syscall.h: fix doc text for syscall_get_arch()")
> Reviewed-by: Andy Lutomirski # for x86
> Reviewed-by: Palmer Dabbelt
> Acked-by: Paul Moore
> Acked-by: Paul Burton # M
On Tue, Feb 12, 2019 at 9:50 AM Tom Hromatka wrote:
> On 2/11/19 11:54 AM, Tom Hromatka wrote:
> > PowerPC experts,
> >
> > Paul Moore and I are working on the v2.4 release of libseccomp,
> > and as part of this work I need to update the syscall table for
> >
dd asm/syscall.h
> syscall_get_arch: add "struct task_struct *" argument
> selftests/ptrace: add a test case for PTRACE_GET_SYSCALL_INFO
>
> Elvira Khabirova (2):
> powerpc/ptrace: replace ptrace_report_syscall() with a tracehook call
> ptrace: add PTRACE_GET_SYSC
not
> if we just want to delete them anyway.
>
> As a starting point, remove all index-files and references to 00-INDEX and
> see where the discussion is going.
>
> Again, sorry for the insanely wide distribution.
>
> Signed-off-by: Henrik Austad
...
> Signed-off-by:
| 6 +++---
> kernel/trace/trace_printk.c | 4 ++--
> lib/raid6/sse2.c | 14 +++---
> sound/soc/fsl/fsl_dma.c | 2 +-
> 20 files changed, 30 insertions(+), 31 deletions(-)
For the audit bits ...
Acked-by: Paul Moore
--
paul moore
www.paul-moore.com
rtions(+), 1 deletions(-)
The audit changes look fine to me, but as I mentioned earlier, this should go
in via the ppc tree and not the audit tree.
Acked-by: Paul Moore
> diff --git a/arch/powerpc/include/asm/syscall.h
> b/arch/powerpc/include/asm/syscall.h index 6fa2708..d1934e5 100644
&
ually
> compiles
>
> Signed-off-by: Richard Guy Briggs
> ---
> arch/powerpc/include/asm/syscall.h |7 +++
> include/uapi/linux/audit.h |1 +
> 2 files changed, 8 insertions(+), 0 deletions(-)
Looks reasonable to me from an audit perspective, but I'll
64BIT|__AUDIT_ARCH_LE)
> >
> > #define AUDIT_ARCH_S390(EM_S390)
> > #define AUDIT_ARCH_S390X (EM_S390|__AUDIT_ARCH_64BIT)
> > #define AUDIT_ARCH_SH (EM_SH)
>
> IBM would know for certain but I wasn't aware there was a PPCLE (32bit
> compat).
FWIW, I've heard the same thing from IBM folks off-list.
--
paul moore
security and virtualization @ redhat
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
56 matches
Mail list logo
