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
| ||
|
Message-ID: <CAHC9VhRXUe_RiTT1VqkA_Jv08MFCMvYytZkjKcf77EqyVLi-Tw@mail.gmail.com> Date: Sun, 29 Jan 2023 18:37:46 -0500 From: Paul Moore <paul@...l-moore.com> To: Steve Grubb <sgrubb@...hat.com> Cc: Richard Guy Briggs <rgb@...hat.com>, Linux-Audit Mailing List <linux-audit@...hat.com>, LKML <linux-kernel@...r.kernel.org>, io-uring@...r.kernel.org, Eric Paris <eparis@...isplace.org>, Stefan Roesch <shr@...com>, Christian Brauner <brauner@...nel.org>, Jens Axboe <axboe@...nel.dk>, Pavel Begunkov <asml.silence@...il.com> Subject: Re: [PATCH v1 2/2] io_uring,audit: do not log IORING_OP_*GETXATTR On Sat, Jan 28, 2023 at 12:26 PM Steve Grubb <sgrubb@...hat.com> wrote: > On Friday, January 27, 2023 5:43:02 PM EST Paul Moore wrote: > > On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs <rgb@...hat.com> wrote: > > > Getting XATTRs is not particularly interesting security-wise. > > > > > > Suggested-by: Steve Grubb <sgrubb@...hat.com> > > > Fixes: a56834e0fafe ("io_uring: add fgetxattr and getxattr support") > > > Signed-off-by: Richard Guy Briggs <rgb@...hat.com> > > > --- > > > io_uring/opdef.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > Depending on your security policy, fetching file data, including > > xattrs, can be interesting from a security perspective. As an > > example, look at the SELinux file/getattr permission. > > > > https://github.com/SELinuxProject/selinux-notebook/blob/main/src/object_cla > > sses_permissions.md#common-file-permissions > > We're mostly interested in setting attributes because that changes policy. > Reading them is not interesting unless the access fails with EPERM. See my earlier comments, SELinux does have provisions for caring about reading xattrs, and now that I look at the rest of the LSMs it looks like Smack cares about reading xattrs too. Regardless of whether a given security policy cares about xattr access, the LSMs support enforcing access on reading xattrs so we need to ensure the audit is setup properly in these cases. > I was updating the user space piece recently and saw there was a bunch of > "new" operations. I was commenting that we need to audit 5 or 6 of the "new" > operations such as IORING_OP_MKDIRATor IORING_OP_SETXATTR. But now that I see > the patch, it looks like they are auditable and we can just let a couple be > skipped. IORING_OP_MADVISE is not interesting as it just gives hiints about > the expected access patterns of memory. If there were an equivalent of > mprotect, that would be of interest, but not madvise. Once again, as discussed previously, it is likely that skipping auditing for IORING_OP_MADVISE is okay, but given that several of the changes in this patchset were incorrect, I'd like a little more thorough investigation before we skip auditing on madvise. > There are some I'm not sure about such as IORING_OP_MSG_RING and > IORING_OP_URING_CMD. What do they do? Look at 4f57f06ce218 ("io_uring: add support for IORING_OP_MSG_RING command") for the patch which added IORING_OP_MSG_RING as it has a decent commit description. As for IORING_OP_URING_CMD, there were lengthy discussions about it on the mailing lists (including audit) back in March 2022 and then later in August on the LSM, SELinux, etc. mailing lists when we landed some patches for it (there were no audit changes). I also covered the IORING_OP_URING_CMD, albeit briefly, in a presentation at LSS-EU last year: https://www.youtube.com/watch?v=AaaH6skUEI8 https://www.paul-moore.com/docs/2022-lss_eu-iouring_lsm-pcmoore-r3.pdf -- paul-moore.com
Powered by blists - more mailing lists