From: russell@coker.com.au (Russell Coker) Date: Fri, 16 Feb 2018 22:05:27 +1100 Subject: [refpolicy] udisks2 and /dev/mem In-Reply-To: References: <2454785.LnChbr6P9C@liv> <2090583.M0PCVYQvNm@liv> Message-ID: <2962087.SU5ME4vmiQ@liv> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 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/