From: russell@coker.com.au (Russell Coker) Date: Fri, 16 Feb 2018 16:59:27 +1100 Subject: [refpolicy] udisks2 and /dev/mem In-Reply-To: <2164891.hfskaxh8Hi@liv> References: <2454785.LnChbr6P9C@liv> <2164891.hfskaxh8Hi@liv> Message-ID: <2090583.M0PCVYQvNm@liv> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Thursday, 15 February 2018 11:36:51 PM AEDT Russell Coker wrote: > > Therefore I can only make a blind guess that a udisksd component is > > crawling /dev and performs a call to access("/dev/mem") to test > > whether this file is readable. Did you have a "type=SYSCALL" entry > > next to the AVC in audit.log, which would tell whether the denied > > access was caused by access() or open()? > > It's openat. Thanks for suggesting looking for the syscall, it explains why > my grep for /dev/mem in udisks2 and all the shared objects it loads didn't > turn up any matches. I'll try and get udisks2 to run under gdb and see > what that reveals. In the source file parted-3.2/libparted/labels/gpt.c from libparted we have the function ped_disk_gpt_init() which calls the function dmi_system_manufacturer() that calls the mem_chunk() function to get access to system memory for EFI data. Access to system memory is via /dev/mem. That function is called from call_init() so it looks like a libparted init issue, so udisks2 probably isn't even requesting that data. It's strange that my laptop is the only one of my systems to trigger this as it only has a 180G disk that uses the old PC partition table. dev_rx_raw_memory(devicekit_disk_t) I'll submit a patch to add the above in a later message. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/