From: nicolas.iooss@m4x.org (Nicolas Iooss)
Date: Fri, 16 Feb 2018 11:04:47 +0100
Subject: [refpolicy] udisks2 and /dev/mem
In-Reply-To: <2090583.M0PCVYQvNm@liv>
References: <2454785.LnChbr6P9C@liv>
	<CAJfZ7==rZfDkbOm1iUGbhVsy9CLOaLQAg3ajk8+LYKVUnH0=sQ@mail.gmail.com>
	<2164891.hfskaxh8Hi@liv> <2090583.M0PCVYQvNm@liv>
Message-ID: <CAJfZ7==tRh27xFX-ie=ssCQ7BD4jB9=yeH7PrN=gNQSbuikTwg@mail.gmail.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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/