[refpolicy] udisks2 and /dev/mem

[russell@coker.com.au (Russell Coker)]

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/