| Message ID | cover.1674682056.git.rgb@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | two suggested iouring op audit updates | expand |
On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > A couple of updates to the iouring ops audit bypass selections suggested in > consultation with Steve Grubb. > > Richard Guy Briggs (2): > io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > io_uring,audit: do not log IORING_OP_*GETXATTR > > io_uring/opdef.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Look fine to me - we should probably add stable to both of them, just to keep things consistent across releases. I can queue them up for 6.3.
On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe <axboe@kernel.dk> wrote: > On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > > A couple of updates to the iouring ops audit bypass selections suggested in > > consultation with Steve Grubb. > > > > Richard Guy Briggs (2): > > io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > > io_uring,audit: do not log IORING_OP_*GETXATTR > > > > io_uring/opdef.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > Look fine to me - we should probably add stable to both of them, just > to keep things consistent across releases. I can queue them up for 6.3. Please hold off until I've had a chance to look them over ...
On 1/27/23 12:42 PM, Paul Moore wrote: > On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe <axboe@kernel.dk> wrote: >> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: >>> A couple of updates to the iouring ops audit bypass selections suggested in >>> consultation with Steve Grubb. >>> >>> Richard Guy Briggs (2): >>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE >>> io_uring,audit: do not log IORING_OP_*GETXATTR >>> >>> io_uring/opdef.c | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> Look fine to me - we should probably add stable to both of them, just >> to keep things consistent across releases. I can queue them up for 6.3. > > Please hold off until I've had a chance to look them over ... I haven't taken anything yet, for things like this I always let it simmer until people have had a chance to do so.
On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe <axboe@kernel.dk> wrote: > On 1/27/23 12:42 PM, Paul Moore wrote: > > On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe <axboe@kernel.dk> wrote: > >> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > >>> A couple of updates to the iouring ops audit bypass selections suggested in > >>> consultation with Steve Grubb. > >>> > >>> Richard Guy Briggs (2): > >>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > >>> io_uring,audit: do not log IORING_OP_*GETXATTR > >>> > >>> io_uring/opdef.c | 4 +++- > >>> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> Look fine to me - we should probably add stable to both of them, just > >> to keep things consistent across releases. I can queue them up for 6.3. > > > > Please hold off until I've had a chance to look them over ... > > I haven't taken anything yet, for things like this I always let it > simmer until people have had a chance to do so. Thanks. FWIW, that sounds very reasonable to me, but I've seen lots of different behaviors across subsystems and wanted to make sure we were on the same page.
On 1/27/23 3:38 PM, Paul Moore wrote: > On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe <axboe@kernel.dk> wrote: >> On 1/27/23 12:42 PM, Paul Moore wrote: >>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe <axboe@kernel.dk> wrote: >>>> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: >>>>> A couple of updates to the iouring ops audit bypass selections suggested in >>>>> consultation with Steve Grubb. >>>>> >>>>> Richard Guy Briggs (2): >>>>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE >>>>> io_uring,audit: do not log IORING_OP_*GETXATTR >>>>> >>>>> io_uring/opdef.c | 4 +++- >>>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>> >>>> Look fine to me - we should probably add stable to both of them, just >>>> to keep things consistent across releases. I can queue them up for 6.3. >>> >>> Please hold off until I've had a chance to look them over ... >> >> I haven't taken anything yet, for things like this I always let it >> simmer until people have had a chance to do so. > > Thanks. FWIW, that sounds very reasonable to me, but I've seen lots > of different behaviors across subsystems and wanted to make sure we > were on the same page. Sounds fair. BTW, can we stop CC'ing closed lists on patch submissions? Getting these: Your message to Linux-audit awaits moderator approval on every reply is really annoying.
On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe <axboe@kernel.dk> wrote: > On 1/27/23 3:38 PM, Paul Moore wrote: > > On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe <axboe@kernel.dk> wrote: > >> On 1/27/23 12:42 PM, Paul Moore wrote: > >>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe <axboe@kernel.dk> wrote: > >>>> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > >>>>> A couple of updates to the iouring ops audit bypass selections suggested in > >>>>> consultation with Steve Grubb. > >>>>> > >>>>> Richard Guy Briggs (2): > >>>>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > >>>>> io_uring,audit: do not log IORING_OP_*GETXATTR > >>>>> > >>>>> io_uring/opdef.c | 4 +++- > >>>>> 1 file changed, 3 insertions(+), 1 deletion(-) > >>>> > >>>> Look fine to me - we should probably add stable to both of them, just > >>>> to keep things consistent across releases. I can queue them up for 6.3. > >>> > >>> Please hold off until I've had a chance to look them over ... > >> > >> I haven't taken anything yet, for things like this I always let it > >> simmer until people have had a chance to do so. > > > > Thanks. FWIW, that sounds very reasonable to me, but I've seen lots > > of different behaviors across subsystems and wanted to make sure we > > were on the same page. > > Sounds fair. BTW, can we stop CC'ing closed lists on patch > submissions? Getting these: > > Your message to Linux-audit awaits moderator approval > > on every reply is really annoying. We kinda need audit related stuff on the linux-audit list, that's our mailing list for audit stuff. However, I agree that it is crap that the linux-audit list is moderated, but unfortunately that isn't something I control (I haven't worked for RH in years, and even then the list owner was really weird about managing the list). Occasionally I grumble about moving the kernel audit development to a linux-audit list on vger but haven't bothered yet, perhaps this is as good a reason as any. Richard, Steve - any chance of opening the linux-audit list?
On 1/27/23 3:53 PM, Paul Moore wrote: > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe <axboe@kernel.dk> wrote: >> On 1/27/23 3:38 PM, Paul Moore wrote: >>> On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe <axboe@kernel.dk> wrote: >>>> On 1/27/23 12:42 PM, Paul Moore wrote: >>>>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe <axboe@kernel.dk> wrote: >>>>>> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: >>>>>>> A couple of updates to the iouring ops audit bypass selections suggested in >>>>>>> consultation with Steve Grubb. >>>>>>> >>>>>>> Richard Guy Briggs (2): >>>>>>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE >>>>>>> io_uring,audit: do not log IORING_OP_*GETXATTR >>>>>>> >>>>>>> io_uring/opdef.c | 4 +++- >>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>>>> >>>>>> Look fine to me - we should probably add stable to both of them, just >>>>>> to keep things consistent across releases. I can queue them up for 6.3. >>>>> >>>>> Please hold off until I've had a chance to look them over ... >>>> >>>> I haven't taken anything yet, for things like this I always let it >>>> simmer until people have had a chance to do so. >>> >>> Thanks. FWIW, that sounds very reasonable to me, but I've seen lots >>> of different behaviors across subsystems and wanted to make sure we >>> were on the same page. >> >> Sounds fair. BTW, can we stop CC'ing closed lists on patch >> submissions? Getting these: >> >> Your message to Linux-audit awaits moderator approval >> >> on every reply is really annoying. > > We kinda need audit related stuff on the linux-audit list, that's our > mailing list for audit stuff. Sure, but then it should be open. Or do separate postings or something. CC'ing a closed list with open lists and sending email to people that are not on that closed list is bad form.
On 2023-01-27 16:02, Jens Axboe wrote: > On 1/27/23 3:53 PM, Paul Moore wrote: > > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe <axboe@kernel.dk> wrote: > >> On 1/27/23 3:38 PM, Paul Moore wrote: > >>> On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe <axboe@kernel.dk> wrote: > >>>> On 1/27/23 12:42 PM, Paul Moore wrote: > >>>>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe <axboe@kernel.dk> wrote: > >>>>>> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > >>>>>>> A couple of updates to the iouring ops audit bypass selections suggested in > >>>>>>> consultation with Steve Grubb. > >>>>>>> > >>>>>>> Richard Guy Briggs (2): > >>>>>>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > >>>>>>> io_uring,audit: do not log IORING_OP_*GETXATTR > >>>>>>> > >>>>>>> io_uring/opdef.c | 4 +++- > >>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-) > >>>>>> > >>>>>> Look fine to me - we should probably add stable to both of them, just > >>>>>> to keep things consistent across releases. I can queue them up for 6.3. > >>>>> > >>>>> Please hold off until I've had a chance to look them over ... > >>>> > >>>> I haven't taken anything yet, for things like this I always let it > >>>> simmer until people have had a chance to do so. > >>> > >>> Thanks. FWIW, that sounds very reasonable to me, but I've seen lots > >>> of different behaviors across subsystems and wanted to make sure we > >>> were on the same page. > >> > >> Sounds fair. BTW, can we stop CC'ing closed lists on patch > >> submissions? Getting these: > >> > >> Your message to Linux-audit awaits moderator approval > >> > >> on every reply is really annoying. > > > > We kinda need audit related stuff on the linux-audit list, that's our > > mailing list for audit stuff. > > Sure, but then it should be open. Or do separate postings or something. > CC'ing a closed list with open lists and sending email to people that > are not on that closed list is bad form. I've made an inquiry. > Jens Axboe - RGB -- Richard Guy Briggs <rgb@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
On Fri, Jan 27, 2023 at 6:02 PM Jens Axboe <axboe@kernel.dk> wrote: > On 1/27/23 3:53 PM, Paul Moore wrote: > > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe <axboe@kernel.dk> wrote: > >> On 1/27/23 3:38 PM, Paul Moore wrote: > >>> On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe <axboe@kernel.dk> wrote: > >>>> On 1/27/23 12:42 PM, Paul Moore wrote: > >>>>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe <axboe@kernel.dk> wrote: > >>>>>> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > >>>>>>> A couple of updates to the iouring ops audit bypass selections suggested in > >>>>>>> consultation with Steve Grubb. > >>>>>>> > >>>>>>> Richard Guy Briggs (2): > >>>>>>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > >>>>>>> io_uring,audit: do not log IORING_OP_*GETXATTR > >>>>>>> > >>>>>>> io_uring/opdef.c | 4 +++- > >>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-) > >>>>>> > >>>>>> Look fine to me - we should probably add stable to both of them, just > >>>>>> to keep things consistent across releases. I can queue them up for 6.3. > >>>>> > >>>>> Please hold off until I've had a chance to look them over ... > >>>> > >>>> I haven't taken anything yet, for things like this I always let it > >>>> simmer until people have had a chance to do so. > >>> > >>> Thanks. FWIW, that sounds very reasonable to me, but I've seen lots > >>> of different behaviors across subsystems and wanted to make sure we > >>> were on the same page. > >> > >> Sounds fair. BTW, can we stop CC'ing closed lists on patch > >> submissions? Getting these: > >> > >> Your message to Linux-audit awaits moderator approval > >> > >> on every reply is really annoying. > > > > We kinda need audit related stuff on the linux-audit list, that's our > > mailing list for audit stuff. > > Sure, but then it should be open. Or do separate postings or something. > CC'ing a closed list with open lists and sending email to people that > are not on that closed list is bad form. Agree, that's why I said in my reply that it was crap that the linux-audit list is moderated and asked Richard/Steve to open it up.
On 1/27/23 4:08 PM, Paul Moore wrote: > On Fri, Jan 27, 2023 at 6:02 PM Jens Axboe <axboe@kernel.dk> wrote: >> On 1/27/23 3:53 PM, Paul Moore wrote: >>> On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe <axboe@kernel.dk> wrote: >>>> On 1/27/23 3:38 PM, Paul Moore wrote: >>>>> On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe <axboe@kernel.dk> wrote: >>>>>> On 1/27/23 12:42 PM, Paul Moore wrote: >>>>>>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe <axboe@kernel.dk> wrote: >>>>>>>> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: >>>>>>>>> A couple of updates to the iouring ops audit bypass selections suggested in >>>>>>>>> consultation with Steve Grubb. >>>>>>>>> >>>>>>>>> Richard Guy Briggs (2): >>>>>>>>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE >>>>>>>>> io_uring,audit: do not log IORING_OP_*GETXATTR >>>>>>>>> >>>>>>>>> io_uring/opdef.c | 4 +++- >>>>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>>>>>> >>>>>>>> Look fine to me - we should probably add stable to both of them, just >>>>>>>> to keep things consistent across releases. I can queue them up for 6.3. >>>>>>> >>>>>>> Please hold off until I've had a chance to look them over ... >>>>>> >>>>>> I haven't taken anything yet, for things like this I always let it >>>>>> simmer until people have had a chance to do so. >>>>> >>>>> Thanks. FWIW, that sounds very reasonable to me, but I've seen lots >>>>> of different behaviors across subsystems and wanted to make sure we >>>>> were on the same page. >>>> >>>> Sounds fair. BTW, can we stop CC'ing closed lists on patch >>>> submissions? Getting these: >>>> >>>> Your message to Linux-audit awaits moderator approval >>>> >>>> on every reply is really annoying. >>> >>> We kinda need audit related stuff on the linux-audit list, that's our >>> mailing list for audit stuff. >> >> Sure, but then it should be open. Or do separate postings or something. >> CC'ing a closed list with open lists and sending email to people that >> are not on that closed list is bad form. > > Agree, that's why I said in my reply that it was crap that the > linux-audit list is moderated and asked Richard/Steve to open it up. And thanks for that, I just skipped it in the reply as it wasn't for me.
On Friday, January 27, 2023 5:53:24 PM EST Paul Moore wrote: > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe <axboe@kernel.dk> wrote: > > On 1/27/23 3:38 PM, Paul Moore wrote: > > > On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe <axboe@kernel.dk> wrote: > > >> On 1/27/23 12:42 PM, Paul Moore wrote: > > >>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe <axboe@kernel.dk> wrote: > > >>>> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > > >>>>> A couple of updates to the iouring ops audit bypass selections > > >>>>> suggested in consultation with Steve Grubb. > > >>>>> > > >>>>> Richard Guy Briggs (2): > > >>>>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > > >>>>> io_uring,audit: do not log IORING_OP_*GETXATTR > > >>>>> > > >>>>> io_uring/opdef.c | 4 +++- > > >>>>> 1 file changed, 3 insertions(+), 1 deletion(-) > > >>>> > > >>>> Look fine to me - we should probably add stable to both of them, > > >>>> just to keep things consistent across releases. I can queue them up > > >>>> for 6.3. > > >>> > > >>> Please hold off until I've had a chance to look them over ... > > >> > > >> I haven't taken anything yet, for things like this I always let it > > >> simmer until people have had a chance to do so. > > > > > > Thanks. FWIW, that sounds very reasonable to me, but I've seen lots > > > of different behaviors across subsystems and wanted to make sure we > > > were on the same page. > > > > Sounds fair. BTW, can we stop CC'ing closed lists on patch > > submissions? Getting these: > > > > Your message to Linux-audit awaits moderator approval > > > > on every reply is really annoying. > > We kinda need audit related stuff on the linux-audit list, that's our > mailing list for audit stuff. > > However, I agree that it is crap that the linux-audit list is > moderated, but unfortunately that isn't something I control (I haven't > worked for RH in years, and even then the list owner was really weird > about managing the list). Occasionally I grumble about moving the > kernel audit development to a linux-audit list on vger but haven't > bothered yet, perhaps this is as good a reason as any. > > Richard, Steve - any chance of opening the linux-audit list? Unfortunately, it really has to be this way. I deleted 10 spam emails yesterday. It seems like some people subscribed to this list are compromised. Because everytime there is a legit email, it's followed in a few seconds by a spam email. Anyways, all legit email will be approved without needing to be subscribed. -Steve
On Sat, Jan 28, 2023 at 11:48 AM Steve Grubb <sgrubb@redhat.com> wrote: > On Friday, January 27, 2023 5:53:24 PM EST Paul Moore wrote: > > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe <axboe@kernel.dk> wrote: > > > On 1/27/23 3:38 PM, Paul Moore wrote: > > > > On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe <axboe@kernel.dk> wrote: > > > >> On 1/27/23 12:42 PM, Paul Moore wrote: > > > >>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe <axboe@kernel.dk> wrote: > > > >>>> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > > > >>>>> A couple of updates to the iouring ops audit bypass selections > > > >>>>> suggested in consultation with Steve Grubb. > > > >>>>> > > > >>>>> Richard Guy Briggs (2): > > > >>>>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > > > >>>>> io_uring,audit: do not log IORING_OP_*GETXATTR > > > >>>>> > > > >>>>> io_uring/opdef.c | 4 +++- > > > >>>>> 1 file changed, 3 insertions(+), 1 deletion(-) > > > >>>> > > > >>>> Look fine to me - we should probably add stable to both of them, > > > >>>> just to keep things consistent across releases. I can queue them up > > > >>>> for 6.3. > > > >>> > > > >>> Please hold off until I've had a chance to look them over ... > > > >> > > > >> I haven't taken anything yet, for things like this I always let it > > > >> simmer until people have had a chance to do so. > > > > > > > > Thanks. FWIW, that sounds very reasonable to me, but I've seen lots > > > > of different behaviors across subsystems and wanted to make sure we > > > > were on the same page. > > > > > > Sounds fair. BTW, can we stop CC'ing closed lists on patch > > > submissions? Getting these: > > > > > > Your message to Linux-audit awaits moderator approval > > > > > > on every reply is really annoying. > > > > We kinda need audit related stuff on the linux-audit list, that's our > > mailing list for audit stuff. > > > > However, I agree that it is crap that the linux-audit list is > > moderated, but unfortunately that isn't something I control (I haven't > > worked for RH in years, and even then the list owner was really weird > > about managing the list). Occasionally I grumble about moving the > > kernel audit development to a linux-audit list on vger but haven't > > bothered yet, perhaps this is as good a reason as any. > > > > Richard, Steve - any chance of opening the linux-audit list? > > Unfortunately, it really has to be this way. I deleted 10 spam emails > yesterday. It seems like some people subscribed to this list are compromised. > Because everytime there is a legit email, it's followed in a few seconds by a > spam email. > > Anyways, all legit email will be approved without needing to be subscribed. The problem is that other subsystem developers who aren't subscribed to the linux-audit list end up getting held mail notices (see the comments from Jens). The moderation of linux-audit, as permissive as it may be for proper emails, is a problem for upstream linux audit development, I would say much more so than 10/day mails. If you are unable/unwilling to switch linux-audit over to an open mailing list we should revisit moving over to a vger list; at least for upstream kernel development, you are welcome to stick with the existing redhat.com list for discussion of your userspace tools.