[refpolicy] udisks2 and /dev/mem

[refpolicy] udisks2 and /dev/mem

[Russell Coker]

type=AVC msg=audit(1518580690.273:39): avc:  denied  { read } for  pid=566 
comm="udisksd" name="mem" dev="devtmpfs" ino=1027 
scontext=system_u:system_r:devicekit_disk_t:s0 
tcontext=system_u:object_r:memory_device_t:s0 tclass=chr_file permissive=0

Does anyone know why udisksd from the udisks2 package needs to access /dev/
mem?

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

[refpolicy] udisks2 and /dev/mem

[Nicolas Iooss]

On Wed, Feb 14, 2018 at 5:03 AM, Russell Coker via refpolicy
<refpolicy@oss.tresys.com> wrote:
> type=AVC msg=audit(1518580690.273:39): avc:  denied  { read } for  pid=566
> comm="udisksd" name="mem" dev="devtmpfs" ino=1027
> scontext=system_u:system_r:devicekit_disk_t:s0
> tcontext=system_u:object_r:memory_device_t:s0 tclass=chr_file permissive=0
>
> Does anyone know why udisksd from the udisks2 package needs to access /dev/
> mem?

Hi,
I quickly searched the package source and grepped the libraries used
by udisksd in order to find which one would access /dev/mem and found
nothing. When I install udisks2 in a simple virtual machine which has
/dev/mem (the kernels I use are built without CONFIG_DEVMEM), this AVC
does not appear.

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()?

Nicolas

[refpolicy] udisks2 and /dev/mem

[Russell Coker]

On Thursday, 15 February 2018 10:40:34 PM AEDT Nicolas Iooss wrote:
> On Wed, Feb 14, 2018 at 5:03 AM, Russell Coker via refpolicy
> 
> <refpolicy@oss.tresys.com> wrote:
> > type=AVC msg=audit(1518580690.273:39): avc:  denied  { read } for  pid=566
> > comm="udisksd" name="mem" dev="devtmpfs" ino=1027
> > scontext=system_u:system_r:devicekit_disk_t:s0
> > tcontext=system_u:object_r:memory_device_t:s0 tclass=chr_file permissive=0
> > 
> > Does anyone know why udisksd from the udisks2 package needs to access
> > /dev/
> > mem?
> 
> Hi,
> I quickly searched the package source and grepped the libraries used
> by udisksd in order to find which one would access /dev/mem and found
> nothing. When I install udisks2 in a simple virtual machine which has
> /dev/mem (the kernels I use are built without CONFIG_DEVMEM), this AVC
> does not appear.

This currently only happens on my laptop.  I haven't seen it happen on a VM.  
It might be related to some aspect of the configuration of my laptop, 
encrypted disks or something.  Although it doesn't occur on my workstation 
with encrypted disks.

> 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.

# ausearch --format interpret -a 39
----
type=PROCTITLE msg=audit(14/02/18 14:58:10.273:39) : proctitle=/usr/lib/
udisks2/udisksd
type=SYSCALL msg=audit(14/02/18 14:58:10.273:39) : arch=x86_64 syscall=openat 
success=no exit=EACCES(Permission denied) a0=0xffffffffffffff9c 
a1=0x7fd666a6bc29 a2=O_RDONLY a3=0x0 items=0 ppid=1 pid=566 auid=unset 
uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root 
fsgid=root tty=(none) ses=unset comm=udisksd exe=/usr/lib/udisks2/udisksd 
subj=system_u:system_r:devicekit_disk_t:s0 key=(null)
type=AVC msg=audit(14/02/18 14:58:10.273:39) : avc:  denied  { read } for  
pid=566 comm=udisksd name=mem dev="devtmpfs" ino=1027 
scontext=system_u:system_r:devicekit_disk_t:s0 
tcontext=system_u:object_r:memory_device_t:s0 tclass=chr_file permissive=0

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

[refpolicy] udisks2 and /dev/mem

[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/

[refpolicy] udisks2 and /dev/mem

[Nicolas Iooss]

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/

[refpolicy] udisks2 and /dev/mem

[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/