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
| ||
|
Date: Thu, 30 Jul 2020 10:03:41 +0200 From: peter enderborg <peter.enderborg@...y.com> To: ThiƩbaud Weksteen <tweek@...gle.com>, Paul Moore <paul@...l-moore.com> CC: Steven Rostedt <rostedt@...dmis.org>, Stephen Smalley <stephen.smalley.work@...il.com>, Nick Kralevich <nnk@...gle.com>, Joel Fernandes <joelaf@...gle.com>, Eric Paris <eparis@...isplace.org>, Ingo Molnar <mingo@...hat.com>, Mauro Carvalho Chehab <mchehab+huawei@...nel.org>, "David S. Miller" <davem@...emloft.net>, Rob Herring <robh@...nel.org>, linux-kernel <linux-kernel@...r.kernel.org>, SElinux list <selinux@...r.kernel.org> Subject: Re: [PATCH] selinux: add tracepoint on denials On 7/28/20 6:02 PM, ThiƩbaud Weksteen wrote: > On Tue, Jul 28, 2020 at 5:12 PM Paul Moore <paul@...l-moore.com> wrote: >> Perhaps it would be helpful if you provided an example of how one >> would be expected to use this new tracepoint? That would help put >> things in the proper perspective. > The best example is the one I provided in the commit message, that is > using perf (or a perf equivalent), to hook onto that tracepoint. > >> Well, to be honest, the very nature of this tracepoint is duplicating >> the AVC audit record with a focus on using perf to establish a full >> backtrace at the expense of reduced information. At least that is how >> it appears to me. > I see both methods as complementary. By default, the kernel itself can > do some reporting (i.e avc message) on which process triggered the > denial, what was the context, etc. This is useful even in production > and doesn't require any extra tooling. > The case for adding this tracepoint can be seen as advanced debugging. > That is, once an avc denial has been confirmed, a developer can use > this tracepoint to surface the userland stacktrace. It requires more > userland tools and symbols on the userland binaries. I think from development view you would like to have a better way to trap this events in userspace. One idea that I have is is to have more outcomes from a rule. We have today allow, dontaudit, auditallow i think it would be good to have signal sent too. "signal-xxx-allow" for some set of signals. SIGBUS, SIGSEGV, SIGABRT maybe. That will be a good way to pickup the problem with a debugger or generate a a core file. I have also done some selinux trace functions. I think they collide with this set, but I think I can rebase them upon yours and see if they give some more functionality. I see this functionality very much needed in some form.
Powered by blists - more mailing lists