[refpolicy] udisks2 and /dev/mem

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

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890587

Thanks for all that information.  I've filed a Debian bug report about this.

On Friday, 16 February 2018 9:04:47 PM AEDT Nicolas Iooss wrote:
> On Fri, Feb 16, 2018 at 6:59 AM, Russell Coker <russell@coker.com.au> wrote:
> > 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.
> Which distribution are you using? There is no call to
> dmi_system_manufacturer() in parted's master branch [1] but Debian
> carries a patch which adds it [2]. This patch is named gptsync.patch
> and its description is (from [3]):
> 
>     gpt syncing for intel macs
>     On Intel Mac systems, write a synced MBR rather than a protective MBR.
> 
> If this patch is specific to Debian, I suggest encapsulating the rule
> which enables the access to /dev/mem in a ifdef(`distro_debian' block.
> 
> > 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.
> 
> It does not need the executable permission (it only reads memory).
> 
> For information, I do not understand why libparted relies on /dev/mem
> for getting DMI data. The patch claims to come from dmidecode so I ran
> this command on my system without /dev/mem and it worked fine, by
> decoding /sys/firmware/dmi/tables/DMI instead of /dev/mem. Anyway I
> agree this looks like a libparted init issue, caused by a distribution
> patch.
> 
> Cheers,
> Nicolas
> 
> [1] https://git.savannah.gnu.org/cgit/parted.git/tree/libparted/labels/gpt.c
> [2] https://sources.debian.org/patches/parted/3.2-20/gptsync.patch/ [3]
> https://sources.debian.org/patches/parted/3.2-20/


-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/