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/
On Wed, Feb 14, 2018 at 5:03 AM, Russell Coker via refpolicy
<[email protected]> 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
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
>
> <[email protected]> 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/
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/
On Fri, Feb 16, 2018 at 6:59 AM, Russell Coker <[email protected]> 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/
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 <[email protected]> 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/