Should audit_seccomp check audit_enabled?

Should audit_seccomp check audit_enabled?

[Andy Lutomirski]

I would argue that, if auditing is off, audit_seccomp shouldn't do
anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
policy, and seccomp signals might be ordinary behavior that's internal
to the seccomp-using application.  IOW, for people with audit compiled
in and subscribed by journald but switched off, I think that the
records shouldn't be emitted.

If you agree, I can send the two-line patch.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: Should audit_seccomp check audit_enabled?

[Kees Cook]

On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> I would argue that, if auditing is off, audit_seccomp shouldn't do
> anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
> policy, and seccomp signals might be ordinary behavior that's internal
> to the seccomp-using application.  IOW, for people with audit compiled
> in and subscribed by journald but switched off, I think that the
> records shouldn't be emitted.
>
> If you agree, I can send the two-line patch.

I think signr==0 states (which I would identify as "intended
behavior") don't need to be reported under any situation, but audit
folks wanted to keep it around.

-Kees

-- 
Kees Cook
Chrome OS Security

Re: Should audit_seccomp check audit_enabled?

[Richard Guy Briggs]

On 15/10/23, Andy Lutomirski wrote:
> I would argue that, if auditing is off, audit_seccomp shouldn't do
> anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
> policy, and seccomp signals might be ordinary behavior that's internal
> to the seccomp-using application.  IOW, for people with audit compiled
> in and subscribed by journald but switched off, I think that the
> records shouldn't be emitted.
> 
> If you agree, I can send the two-line patch.

This sounds reasonable to me.  It isn't an AVC.  Steve?  Paul?

> --Andy

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

Re: Should audit_seccomp check audit_enabled?

[Richard Guy Briggs]

On 15/10/23, Andy Lutomirski wrote:
> I would argue that, if auditing is off, audit_seccomp shouldn't do
> anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
> policy, and seccomp signals might be ordinary behavior that's internal
> to the seccomp-using application.  IOW, for people with audit compiled
> in and subscribed by journald but switched off, I think that the
> records shouldn't be emitted.
> 
> If you agree, I can send the two-line patch.

This sounds reasonable to me.  It isn't an AVC.  Steve?  Paul?

> --Andy

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

Re: Should audit_seccomp check audit_enabled?

[Paul Moore]

On Fri, Oct 23, 2015 at 1:01 PM, Kees Cook <keescook@chromium.org> wrote:
> On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> I would argue that, if auditing is off, audit_seccomp shouldn't do
>> anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
>> policy, and seccomp signals might be ordinary behavior that's internal
>> to the seccomp-using application.  IOW, for people with audit compiled
>> in and subscribed by journald but switched off, I think that the
>> records shouldn't be emitted.
>>
>> If you agree, I can send the two-line patch.
>
> I think signr==0 states (which I would identify as "intended
> behavior") don't need to be reported under any situation, but audit
> folks wanted to keep it around.

Wearing my libseccomp hat, I would like some logging when the seccomp
filter triggers a result other than allow.  I don't care if this is
via audit or printk(), I just want some notification.  If we go the
printk route and people really don't want to see anything in their
logs, I suppose we could always add a sysctl knob to turn off the
message completely (we would still need to do whatever audit records
are required, see below).

Wearing my audit hat, I want to make sure we tick off all the right
boxes for the various certifications that people care about.  Steve
Grubb has commented on what he needs in the past, although I'm not
sure it was on-list, so I'll ask him to repeat it here.

-- 
paul moore
www.paul-moore.com

Re: Should audit_seccomp check audit_enabled?

[Steve Grubb]

On Friday, October 23, 2015 03:38:05 PM Paul Moore wrote:
> On Fri, Oct 23, 2015 at 1:01 PM, Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <luto@amacapital.net> 
wrote:
> >> I would argue that, if auditing is off, audit_seccomp shouldn't do
> >> anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
> >> policy, and seccomp signals might be ordinary behavior that's internal
> >> to the seccomp-using application.  IOW, for people with audit compiled
> >> in and subscribed by journald but switched off, I think that the
> >> records shouldn't be emitted.
> >> 
> >> If you agree, I can send the two-line patch.
> > 
> > I think signr==0 states (which I would identify as "intended
> > behavior") don't need to be reported under any situation, but audit
> > folks wanted to keep it around.
> 
> Wearing my libseccomp hat, I would like some logging when the seccomp
> filter triggers a result other than allow.  I don't care if this is
> via audit or printk(), I just want some notification.  If we go the
> printk route and people really don't want to see anything in their
> logs, I suppose we could always add a sysctl knob to turn off the
> message completely (we would still need to do whatever audit records
> are required, see below).
> 
> Wearing my audit hat, I want to make sure we tick off all the right
> boxes for the various certifications that people care about.  Steve
> Grubb has commented on what he needs in the past, although I'm not
> sure it was on-list, so I'll ask him to repeat it here.

I went back and reviewed my notes since this came up in the current Common 
Criteria evaluation. What we decided to do is treat syscall failures which 
failed due to seccomp the same as syscall failures caused by dropping 
capabilities. Both are opt-in DAC policies. That means we don't care. Do 
whatever you like. :-)

-Steve

Re: Should audit_seccomp check audit_enabled?

[Paul Moore]

On Fri, Oct 23, 2015 at 4:51 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Friday, October 23, 2015 03:38:05 PM Paul Moore wrote:
>> On Fri, Oct 23, 2015 at 1:01 PM, Kees Cook <keescook@chromium.org> wrote:
>> > On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <luto@amacapital.net>
> wrote:
>> >> I would argue that, if auditing is off, audit_seccomp shouldn't do
>> >> anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
>> >> policy, and seccomp signals might be ordinary behavior that's internal
>> >> to the seccomp-using application.  IOW, for people with audit compiled
>> >> in and subscribed by journald but switched off, I think that the
>> >> records shouldn't be emitted.
>> >>
>> >> If you agree, I can send the two-line patch.
>> >
>> > I think signr==0 states (which I would identify as "intended
>> > behavior") don't need to be reported under any situation, but audit
>> > folks wanted to keep it around.
>>
>> Wearing my libseccomp hat, I would like some logging when the seccomp
>> filter triggers a result other than allow.  I don't care if this is
>> via audit or printk(), I just want some notification.  If we go the
>> printk route and people really don't want to see anything in their
>> logs, I suppose we could always add a sysctl knob to turn off the
>> message completely (we would still need to do whatever audit records
>> are required, see below).
>>
>> Wearing my audit hat, I want to make sure we tick off all the right
>> boxes for the various certifications that people care about.  Steve
>> Grubb has commented on what he needs in the past, although I'm not
>> sure it was on-list, so I'll ask him to repeat it here.
>
> I went back and reviewed my notes since this came up in the current Common
> Criteria evaluation. What we decided to do is treat syscall failures which
> failed due to seccomp the same as syscall failures caused by dropping
> capabilities. Both are opt-in DAC policies. That means we don't care. Do
> whatever you like. :-)

Thanks Steve.

Andy, is your objection that you don't want to see any seccomp
messages, or just seccomp audit records when audit is disabled?

-- 
paul moore
www.paul-moore.com

Re: Should audit_seccomp check audit_enabled?

[Andy Lutomirski]

On Oct 23, 2015 10:01 AM, "Kees Cook" <keescook@chromium.org> wrote:
>
> On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> > I would argue that, if auditing is off, audit_seccomp shouldn't do
> > anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
> > policy, and seccomp signals might be ordinary behavior that's internal
> > to the seccomp-using application.  IOW, for people with audit compiled
> > in and subscribed by journald but switched off, I think that the
> > records shouldn't be emitted.
> >
> > If you agree, I can send the two-line patch.
>
> I think signr==0 states (which I would identify as "intended
> behavior") don't need to be reported under any situation, but audit
> folks wanted to keep it around.

Even if there is a nonzero signr, it could just be a program opting to
trap and emulate one of its own syscalls.

--Andy

Re: Should audit_seccomp check audit_enabled?

[Andy Lutomirski]

On Fri, Oct 23, 2015 at 1:58 PM, Paul Moore <paul@paul-moore.com> wrote:
> On Fri, Oct 23, 2015 at 4:51 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>> On Friday, October 23, 2015 03:38:05 PM Paul Moore wrote:
>>> On Fri, Oct 23, 2015 at 1:01 PM, Kees Cook <keescook@chromium.org> wrote:
>>> > On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <luto@amacapital.net>
>> wrote:
>>> >> I would argue that, if auditing is off, audit_seccomp shouldn't do
>>> >> anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
>>> >> policy, and seccomp signals might be ordinary behavior that's internal
>>> >> to the seccomp-using application.  IOW, for people with audit compiled
>>> >> in and subscribed by journald but switched off, I think that the
>>> >> records shouldn't be emitted.
>>> >>
>>> >> If you agree, I can send the two-line patch.
>>> >
>>> > I think signr==0 states (which I would identify as "intended
>>> > behavior") don't need to be reported under any situation, but audit
>>> > folks wanted to keep it around.
>>>
>>> Wearing my libseccomp hat, I would like some logging when the seccomp
>>> filter triggers a result other than allow.  I don't care if this is
>>> via audit or printk(), I just want some notification.  If we go the
>>> printk route and people really don't want to see anything in their
>>> logs, I suppose we could always add a sysctl knob to turn off the
>>> message completely (we would still need to do whatever audit records
>>> are required, see below).
>>>
>>> Wearing my audit hat, I want to make sure we tick off all the right
>>> boxes for the various certifications that people care about.  Steve
>>> Grubb has commented on what he needs in the past, although I'm not
>>> sure it was on-list, so I'll ask him to repeat it here.
>>
>> I went back and reviewed my notes since this came up in the current Common
>> Criteria evaluation. What we decided to do is treat syscall failures which
>> failed due to seccomp the same as syscall failures caused by dropping
>> capabilities. Both are opt-in DAC policies. That means we don't care. Do
>> whatever you like. :-)
>
> Thanks Steve.
>
> Andy, is your objection that you don't want to see any seccomp
> messages, or just seccomp audit records when audit is disabled?
>

My objection is that people who have audit compiled in but disabled at
runtime shouldn't have the overhead or the log noise from these
messages.  If people want the messages, then I think they should turn
on audit (auditctl -e 1 or whatever).

--Andy

Re: Should audit_seccomp check audit_enabled?

[Kees Cook]

On Fri, Oct 23, 2015 at 2:07 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Oct 23, 2015 10:01 AM, "Kees Cook" <keescook@chromium.org> wrote:
>>
>> On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> > I would argue that, if auditing is off, audit_seccomp shouldn't do
>> > anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
>> > policy, and seccomp signals might be ordinary behavior that's internal
>> > to the seccomp-using application.  IOW, for people with audit compiled
>> > in and subscribed by journald but switched off, I think that the
>> > records shouldn't be emitted.
>> >
>> > If you agree, I can send the two-line patch.
>>
>> I think signr==0 states (which I would identify as "intended
>> behavior") don't need to be reported under any situation, but audit
>> folks wanted to keep it around.
>
> Even if there is a nonzero signr, it could just be a program opting to
> trap and emulate one of its own syscalls.

At present, that is a rare situation. Programs tend to be ptrace
managed externally. Is there anything catching SIGSYS itself?

-Kees

-- 
Kees Cook
Chrome OS Security

Re: Should audit_seccomp check audit_enabled?

[Kees Cook]

On Fri, Oct 23, 2015 at 2:07 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Oct 23, 2015 10:01 AM, "Kees Cook" <keescook@chromium.org> wrote:
>>
>> On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> > I would argue that, if auditing is off, audit_seccomp shouldn't do
>> > anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
>> > policy, and seccomp signals might be ordinary behavior that's internal
>> > to the seccomp-using application.  IOW, for people with audit compiled
>> > in and subscribed by journald but switched off, I think that the
>> > records shouldn't be emitted.
>> >
>> > If you agree, I can send the two-line patch.
>>
>> I think signr==0 states (which I would identify as "intended
>> behavior") don't need to be reported under any situation, but audit
>> folks wanted to keep it around.
>
> Even if there is a nonzero signr, it could just be a program opting to
> trap and emulate one of its own syscalls.

At present, that is a rare situation. Programs tend to be ptrace
managed externally. Is there anything catching SIGSYS itself?

-Kees

-- 
Kees Cook
Chrome OS Security

Re: Should audit_seccomp check audit_enabled?

[Andy Lutomirski]

On Fri, Oct 23, 2015 at 2:22 PM, Kees Cook <keescook@chromium.org> wrote:
> On Fri, Oct 23, 2015 at 2:07 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Oct 23, 2015 10:01 AM, "Kees Cook" <keescook@chromium.org> wrote:
>>>
>>> On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> > I would argue that, if auditing is off, audit_seccomp shouldn't do
>>> > anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
>>> > policy, and seccomp signals might be ordinary behavior that's internal
>>> > to the seccomp-using application.  IOW, for people with audit compiled
>>> > in and subscribed by journald but switched off, I think that the
>>> > records shouldn't be emitted.
>>> >
>>> > If you agree, I can send the two-line patch.
>>>
>>> I think signr==0 states (which I would identify as "intended
>>> behavior") don't need to be reported under any situation, but audit
>>> folks wanted to keep it around.
>>
>> Even if there is a nonzero signr, it could just be a program opting to
>> trap and emulate one of its own syscalls.
>
> At present, that is a rare situation. Programs tend to be ptrace
> managed externally. Is there anything catching SIGSYS itself?
>

I wrote one once.  I also wrote a whole set of patches for libseccomp
to make it easier that never went anywhere -- I should dust those off
and package them into their own library.

--Andy

Re: Should audit_seccomp check audit_enabled?

[Paul Moore]

On October 23, 2015 5:30:45 PM Andy Lutomirski <luto@amacapital.net> wrote:

> On Fri, Oct 23, 2015 at 2:22 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Fri, Oct 23, 2015 at 2:07 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Oct 23, 2015 10:01 AM, "Kees Cook" <keescook@chromium.org> wrote:
>>>>
>>>> On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> > I would argue that, if auditing is off, audit_seccomp shouldn't do
>>>> > anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
>>>> > policy, and seccomp signals might be ordinary behavior that's internal
>>>> > to the seccomp-using application.  IOW, for people with audit compiled
>>>> > in and subscribed by journald but switched off, I think that the
>>>> > records shouldn't be emitted.
>>>> >
>>>> > If you agree, I can send the two-line patch.
>>>>
>>>> I think signr==0 states (which I would identify as "intended
>>>> behavior") don't need to be reported under any situation, but audit
>>>> folks wanted to keep it around.
>>>
>>> Even if there is a nonzero signr, it could just be a program opting to
>>> trap and emulate one of its own syscalls.
>>
>> At present, that is a rare situation. Programs tend to be ptrace
>> managed externally. Is there anything catching SIGSYS itself?
>>
>
> I wrote one once.  I also wrote a whole set of patches for libseccomp
> to make it easier that never went anywhere -- I should dust those off
> and package them into their own library.

It has been a while since we discussed those patches, but if I remember 
correctly it was going to be very difficult to do it in an arch agnostic 
way and that was a concern.

--
paul moore
www.paul-moore.com

Re: Should audit_seccomp check audit_enabled?

[Paul Moore]

On October 23, 2015 5:30:45 PM Andy Lutomirski <luto@amacapital.net> wrote:

> On Fri, Oct 23, 2015 at 2:22 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Fri, Oct 23, 2015 at 2:07 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Oct 23, 2015 10:01 AM, "Kees Cook" <keescook@chromium.org> wrote:
>>>>
>>>> On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> > I would argue that, if auditing is off, audit_seccomp shouldn't do
>>>> > anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
>>>> > policy, and seccomp signals might be ordinary behavior that's internal
>>>> > to the seccomp-using application.  IOW, for people with audit compiled
>>>> > in and subscribed by journald but switched off, I think that the
>>>> > records shouldn't be emitted.
>>>> >
>>>> > If you agree, I can send the two-line patch.
>>>>
>>>> I think signr==0 states (which I would identify as "intended
>>>> behavior") don't need to be reported under any situation, but audit
>>>> folks wanted to keep it around.
>>>
>>> Even if there is a nonzero signr, it could just be a program opting to
>>> trap and emulate one of its own syscalls.
>>
>> At present, that is a rare situation. Programs tend to be ptrace
>> managed externally. Is there anything catching SIGSYS itself?
>>
>
> I wrote one once.  I also wrote a whole set of patches for libseccomp
> to make it easier that never went anywhere -- I should dust those off
> and package them into their own library.

It has been a while since we discussed those patches, but if I remember 
correctly it was going to be very difficult to do it in an arch agnostic 
way and that was a concern.

--
paul moore
www.paul-moore.com