Re: Should audit_seccomp check audit_enabled?
On October 23, 2015 5:30:45 PM Andy Lutomirski wrote: On Fri, Oct 23, 2015 at 2:22 PM, Kees Cook wrote: On Fri, Oct 23, 2015 at 2:07 PM, Andy Lutomirski wrote: On Oct 23, 2015 10:01 AM, "Kees Cook" wrote: On Fri, Oct 23, 2015 at 9:19 AM, 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should audit_seccomp check audit_enabled?
On Fri, Oct 23, 2015 at 2:22 PM, Kees Cook wrote: > On Fri, Oct 23, 2015 at 2:07 PM, Andy Lutomirski wrote: >> On Oct 23, 2015 10:01 AM, "Kees Cook" wrote: >>> >>> On Fri, Oct 23, 2015 at 9:19 AM, 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. >>> >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should audit_seccomp check audit_enabled?
On Fri, Oct 23, 2015 at 2:07 PM, Andy Lutomirski wrote: > On Oct 23, 2015 10:01 AM, "Kees Cook" wrote: >> >> On Fri, Oct 23, 2015 at 9:19 AM, 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. >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should audit_seccomp check audit_enabled?
On Fri, Oct 23, 2015 at 1:58 PM, Paul Moore wrote: > On Fri, Oct 23, 2015 at 4:51 PM, Steve Grubb wrote: >> On Friday, October 23, 2015 03:38:05 PM Paul Moore wrote: >>> On Fri, Oct 23, 2015 at 1:01 PM, Kees Cook wrote: >>> > On Fri, Oct 23, 2015 at 9:19 AM, 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. >>> > >>> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should audit_seccomp check audit_enabled?
On Oct 23, 2015 10:01 AM, "Kees Cook" wrote: > > On Fri, Oct 23, 2015 at 9:19 AM, 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should audit_seccomp check audit_enabled?
On Fri, Oct 23, 2015 at 4:51 PM, Steve Grubb wrote: > On Friday, October 23, 2015 03:38:05 PM Paul Moore wrote: >> On Fri, Oct 23, 2015 at 1:01 PM, Kees Cook wrote: >> > On Fri, Oct 23, 2015 at 9:19 AM, 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. >> > >> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should audit_seccomp check audit_enabled?
On Friday, October 23, 2015 03:38:05 PM Paul Moore wrote: > On Fri, Oct 23, 2015 at 1:01 PM, Kees Cook wrote: > > On Fri, Oct 23, 2015 at 9:19 AM, 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. > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should audit_seccomp check audit_enabled?
On Fri, Oct 23, 2015 at 1:01 PM, Kees Cook wrote: > On Fri, Oct 23, 2015 at 9:19 AM, 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should audit_seccomp check audit_enabled?
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should audit_seccomp check audit_enabled?
On Fri, Oct 23, 2015 at 9:19 AM, 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
