On Sun, May 6, 2018 at 7:36 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Sun, May 6, 2018 at 2:31 PM, Paul Moore <p...@paul-moore.com> wrote:
>> On Thu, May 3, 2018 at 9:08 PM, Tyler Hicks <tyhi...@canonical.com> wrote:
>>> Seccomp received improved logging
ded to explain, among other
> things, that event filtering is performed in seccomp_log()
Kees, are you still okay with v3? Also, are you okay with these
patches going in via the audit tree, or would you prefer to take them
via seccomp? I've got a slight preference for the audit tree myself,
On Thu, May 3, 2018 at 4:42 PM, Steve Grubb <sgr...@redhat.com> wrote:
> On Thursday, May 3, 2018 4:18:26 PM EDT Paul Moore wrote:
>> On Wed, May 2, 2018 at 2:18 PM, Steve Grubb <sgr...@redhat.com> wrote:
>> > On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wr
reading the actions_logged sysctl.
>
> ACK for the format of the records.
I just wanted to clarify the record format with you Steve ... the
"actions" and "old-actions" fields may not be included in the record
in cases where there is an error building the action value string, are
you okay with that or would you prefer the fields to always be
included but with a "?" for the value?
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
; if (!log)
> return;
>
> audit_seccomp(syscall, signr, action);
> }
>
> But if there isn't some other need for a v3, I can just make this
> change when I commit.
>
> Thanks for fixing this up!
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 1, 2018 at 12:41 PM, Steve Grubb <sgr...@redhat.com> wrote:
> On Tuesday, May 1, 2018 11:18:55 AM EDT Paul Moore wrote:
>> On Fri, Apr 27, 2018 at 3:16 PM, Tyler Hicks <tyhi...@canonical.com> wrote:
>> > The decision to log a seccomp action will alway
n the action is RET_KILL_*, RET_LOG, or
> the
> +* FILTER_FLAG_LOG bit was set. The admin has the ability to silence
> +* any action from being logged by removing the action name from the
> +* seccomp_actions_logged sysctl.
> */
> if (log)
&
> + audit_log_untrustedstring(ab, get_task_comm(comm, current));
> + audit_log_d_path_exe(ab, current->mm);
> + audit_log_format(ab, " op=seccomp-logging");
> + if (names)
> + audit_log_format(ab, " actions=\"%s\&q
m not seeing anything that would
cause any backwards compatibility issues for libseccomp. You could
try running the libseccomp tests against a patched kernel to make
sure; the README has all the info you need (pay special attention to
the "live" tests, although those are pretty meager at the mome
On Sat, May 13, 2017 at 7:51 AM, Kees Cook <keesc...@chromium.org> wrote:
> Adjusts for ReST markup and moves under LSM admin guide.
>
> Cc: Paul Moore <p...@paul-moore.com>
> Signed-off-by: Kees Cook <keesc...@chromium.org>
> ---
> .../SELinux.txt => a
10 matches
Mail list logo
