From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Kletzander Subject: Re: What fields should be used for reporting shared memory? Date: Wed, 10 May 2017 14:37:15 +0200 Message-ID: <20170510123715.GH29323@wheatley> References: <20170314114227.GB6248@wheatley> <1547121.n0WsK5LWQM@x2> <20170320113614.GS6248@wheatley> <1621181.giyGs2mlDK@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4088997721745266288==" Return-path: In-Reply-To: <1621181.giyGs2mlDK@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============4088997721745266288== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IvGM3kKqwtniy32b" Content-Disposition: inline --IvGM3kKqwtniy32b Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Mon, Mar 20, 2017 at 06:21:53PM -0400, Steve Grubb wrote: >On Monday, March 20, 2017 7:36:14 AM EDT Martin Kletzander wrote: >> On Thu, Mar 16, 2017 at 09:04:52PM -0400, Steve Grubb wrote: >> >Hello, >> > >> >I apologize for the delay. >> > >> >On Tuesday, March 14, 2017 7:42:27 AM EDT Martin Kletzander wrote: >> >> I am going through the fields in the dictionary and I can't find any >> >> name to use for the following scenario. >> >> >> >> We (libvirt) are running virtual machines and there's a thing nowadays, >> >> that people like to use, called ivshmem (Inter-VM SHared MEMory). From >> >> host's point of view this is just a shared memory region accessed by >> >> multiple VMs (and possibly to host as well). The machine maps the >> >> shared memory given a name (e.g. name "asdf" results in /dev/shm/asdf to >> >> be mapped) *or* it can communicate with a server over UNIX socket and >> >> that server handles interrupts and also tells the client which shared >> >> memory region to map. >> > >> >If both of these result in a path, then I think we want to log it as a >> >resource event. >> >> Yes, and they both are resources in its sense. So you are talking >> particularly about the resrc= field? Should that also have category and >> class or anything else set? Or do you mean we report the path in the >> resrc= field? > >No, I mean we would want the path to the memory in a VIRT_RESOURCE event. :-) >How about something like this: > >type=VIRT_RESOURCE msg=audit(1488441043.591:2977): pid=25464 uid=0 >auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 >msg='virt=kvm resrc=shmem reason=start vm="rhel7.3" uuid=a7708061- >faa0-42ce-897a-e92fb75fcf1d size=4194304 path="/dev/shm/my_shmem1" exe="/usr/ >sbin/libvirtd" hostname=? addr=? terminal=? res=success' > >Having the full path would make it more normal when reporting on files in use. > > >> >> Talking about information we have; in server-less >> >> setup it's the shared memory region that is shared, in the server >> >> scenario it is the socket. That's information we can output. >> > >> >Above you mentioned that the server communicates which region to map. Can >> >you explain what that means? >> >> The server sends a file descriptor to the VM over the socket, details >> can be found here: >> >> http://git.qemu-project.org/?p=qemu.git;a=blob;f=docs/specs/ivshmem-spec.txt >> #l151 > >This one is harder. What we really want to know is the size information. But >libvirtd doesn't have it I assume. That makes it sound like ivshmem should log >it, but it probably doesn't know the reason, vm name, or uuid or anything >else. So, this is probably not good. > >I guess about all that you can say is that a ivshmem-socket is being assigned. >I guess let's do it like this: > >type=VIRT_RESOURCE msg=audit(1488441043.591:2977): pid=25464 uid=0 >auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 >msg='virt=kvm resrc=ivshmem-socket reason=start vm="rhel7.3" uuid=a7708061- >faa0-42ce-897a-e92fb75fcf1d ivshmem="my_shmem2" exe="/usr/sbin/libvirtd" >hostname=? addr=? terminal=? res=success' > Sorry for resurrecting this old thread. I was under the impression that I replied to you and no matter how much I look I can't find the reply. I agree with everything with one exception. I would change the ivshmem="my_shmem2" to path="/path/to/ivshmem.socket". That will also clearly show what VMs share the shm objects. If that's OK with you, I can propose the patch for libvirt in a little while. >-Steve > >> >> So my question is, when starting a domain or hot-(un)plugging, what >> >> naming should we use for this kind of device and what are the things >> >> that we should describe about it? Basically, how would you like the >> >> message to look? >> > >> >We need a record recording what is getting assigned to the VM. In the case >> >of the /dev/shm, you can record that as a path which must be escaped. In >> >the case of the server, I think we still need to understand what is >> >happening. Just recording a socket number or path is not terribly useful >> >in reconstructing the resources given to the VM. >> > >> >Audit events have to tell a story. There is a subect, object, action, and >> >results. It kind of needs to be a sentence. "libvirtd successfully assigned >> >____ to vm-name." >> > >> >-Steve >> > >> >> Thanks in advance for any info. >> >> >> >> Have a nice day, >> >> Martin > > --IvGM3kKqwtniy32b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEiXAnXDYdKAaCyvS1CB/CnyQXht0FAlkTCXsACgkQCB/CnyQX ht2OTg//bYFMsC5X0uuFNwkpxKyoyLdhCmowQPTMwt041CAaz8yCD15oPKFkNWbB g34IfG+QohZAylemHOrkXBb4BRtGYter5D4RZbWbGoDMKcTz7ZXuJSPZwVGCqXCu zbZyXHXDZ2HD/NfrvETdwEogNheoblsNc/EVuhUW48qRihg97Cm751SGArLj6m4p ckyH+Ou/y6Sgu+68XqR+BU5lorz3Bp79FFjQ0WIBuklrYvrf9oC8pq8h7oqQH4ie HI9YtWIPHvi9tEhKRsyRI5wTKxxQbGNjjbxVI9grzJnvkx2hJlyOBcOLYKNd8mOI sP+E9iGRrrhF8F1+2VigoJVmUswZpsWR3eYgZFQDV73gOgCl5rtagwENfraU/Uf/ fm+5cu7Q6kwVhbOA8g9CyGeKyxALUUhE6ITkyVb9I7ZeYJ4tiaq+GyPvV+11h5h3 t/kzjPK9tILzoO6ZU/e8vrK+xDgmQLyMxsFJlSJLXIwxBkgR6fnqfCTffoOkMVu/ dRVxGKsL02/G6s6SjqYKz/5J+y3oDOCmzUjHYPZ/s0GHGvkuQ+BfIDE/M/vYKsvM EkKvurn/OgXXMEgHtgJalVqxAJVCUWsXUW4WJzhmPtRZaaa4oOqHdLROCloxPP+q oz/uWRFz8juAXHCe87/qn8OMB2TZFLQ4SYis4VMihNlr2cI6hw0= =d7+G -----END PGP SIGNATURE----- --IvGM3kKqwtniy32b-- --===============4088997721745266288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4088997721745266288==--