I was able to reproduce this on a device with sdcard support.
[ 171.325196] type=1400 audit(1421405887.930:23): avc: denied { getattr }
for pid=2825 comm="e2fsck" path="/dev/block/zram0" dev="tmpfs" ino=11308
scontext=u:r:fsck:s0 tcontext=u:object_r:swap_block_device:s0
tclass=blk_file permissive=0
It works for us without this rule. This is likely related to vold as
Stephen pointed out calling the Format and Check routines (conjecture).
dmesg:
[ 9.405740] fs_mgr: Running /system/bin/e2fsck on /dev/block/by-name/data
[ 9.719493] e2fsck: e2fsck 1.42.9 (28-Dec-2013)
[ 9.719578] e2fsck: data: clean, 1177/262944 files, 48464/1050112 blocks
[ 9.786987] fs_mgr: Running /system/bin/e2fsck on
/dev/block/by-name/cache
[ 9.817792] e2fsck: e2fsck 1.42.9 (28-Dec-2013)
[ 9.817867] e2fsck: cache: clean, 16/6400 files, 1444/25600 blocks
logcat:
01-16 05:56:01.577 168 191 V vold : /system/bin/fsck_msdos
01-16 05:56:25.902 674 1620 I BootReceiver: Checking for fsck errors
01-16 05:58:07.832 168 191 D Vold : Running /system/bin/e2fsck on
/dev/block/dm-1
01-16 05:58:07.832 168 191 V vold : /system/bin/e2fsck
01-16 05:58:07.940 168 191 I e2fsck : e2fsck 1.42.9 (28-Dec-2013)
01-16 05:58:07.930 2825 2825 W e2fsck : type=1400 audit(0.0:23): avc:
denied { getattr } for path="/dev/block/zram0" dev="tmpfs" ino=11308
scontext=u:r:fsck:s0 tcontext=u:object_r:swap_block_device:s0
tclass=blk_file permissive=0
01-16 05:58:07.995 168 191 I e2fsck : /dev/block/dm-1: clean,
11/485760 files, 34812/1941243 blocks
I see nothing failing, and we don't have this rule. As I said before, and
Jeff also re-iterated, if nothing is failing I would dontaudit this
and look into whats causing this. I don't really have time to debug this is
an entirety at this point in time.
Bill
On Tue, Jan 19, 2016 at 8:24 AM, Jeffrey Vander Stoep <je...@google.com>
wrote:
> Some options:
>
> 1. Ignore it. It's working as intended.
> 2. dontaudit it. Same as above but removes the denial
> 3. track down the source of the denial and fix.
> 4. File a bug against AOSP.
>
> On Tue, Jan 19, 2016 at 8:12 AM Inamdar Sharif <isha...@nvidia.com> wrote:
>
>> Checked init.rc as well, that’s perfectly alright.
>>
>> This avc I am facing while formatting the sdcard as internal storage. Any
>> more ideas??
>>
>> Thanks.
>>
>> -----Original Message-----
>> From: Seandroid-list [mailto:seandroid-list-boun...@tycho.nsa.gov] On
>> Behalf Of Inamdar Sharif
>> Sent: Tuesday, January 19, 2016 12:25 PM
>> To: Roberts, William C; William Roberts
>> Cc: seandroid-list@tycho.nsa.gov
>> Subject: RE: avc denial while enabling zram
>>
>> Yes we do have the same settings from SELinux POV.
>> We have the same code as the AOSP an no more additional changes on top of
>> it.
>>
>> I think I have to check how setting is done in init.rc . May be that’s
>> triggering that (Not sure , will try) I am using swapon_all for swap space
>> in init.rc.
>>
>> Thanks.
>>
>> -----Original Message-----
>> From: Roberts, William C [mailto:william.c.robe...@intel.com]
>> Sent: Tuesday, January 19, 2016 12:50 AM
>> To: William Roberts; Inamdar Sharif
>> Cc: seandroid-list@tycho.nsa.gov
>> Subject: RE: avc denial while enabling zram
>>
>> The only thing we have is the label and for some reason (not sure why
>> offhand) a getattr for the swap_block file for vold.
>>
>> file_contexts:1:# ZRam device configured as swap space
>> file_contexts:2:/dev/block/zram0 u:object_r:swap_block_device:s0
>>
>> vold.te:allow vold swap_block_device:blk_file getattr;
>>
>> We never had to allow any access from fsck. I see no dontaudits, so
>> perhaps were just ignoring the audit messages.
>>
>> Bill
>>
>> From: Seandroid-list [mailto:seandroid-list-boun...@tycho.nsa.gov] On
>> Behalf Of William Roberts
>> Sent: Monday, January 18, 2016 8:53 AM
>> To: Inamdar Sharif <isha...@nvidia.com>
>> Cc: seandroid-list@tycho.nsa.gov
>> Subject: RE: avc denial while enabling zram
>>
>> Interesting, we have swap on zram on Intel devices and I don't recall
>> hearing of anything related to this. So we may just be doing a dontaudit or
>> ignoring it, not sure offhand.
>> On Jan 18, 2016 8:41 AM, "Inamdar Sharif" <isha...@nvidia.com> wrote:
>> >
>> > >>Is that denial actually manifesting itself as some broken
>> functionality?
>> >
>> > As such it is not breaking anything. But this is seen while formatting
>> sdcard as internal storage.
>> >
>> >
>> >
>> > Also, why is fsck getting invoked on swap, especially one backed by
>> zram?
>> >
>> > Not sure about this but got something from the commit message which
>> says that we don’t have swap device on AOSP.
>> >
>> >
>> >
>> > <snip>
>> >
>> > e2fsck is invoked on any partitions marked with the check mount
>> >
>> > option in the fstab file, typically userdata and cache but never
>> >
>> > system. We allow it to read/write the userdata_block_device and
>> >
>> > cache_block_device types but also allow it to read/write the default
>> >
>> > block_device type until we can get the more specific types assigned
>> >
>> > in all of the device-specific policies.
>> >
>> >
>> >
>> > mkswap is invoked on any swap partition defined in the fstab file.
>> >
>> > We introduce a new swap_block_device type for this purpose, to be
>> >
>> > assigned to any such block devices in the device-specific policies,
>> >
>> > and only allow it to read/write such block devices. As there seem to
>> > be
>> >
>> > no devices in AOSP with swap partitions in their fstab files, this
>> > does
>> >
>> > not appear to risk any breakage for existing devices.
>> >
>> > </snip>
>> >
>> >
>> >
>> > Thanks.
>> >
>> >
>> >
>> > From: William Roberts [mailto:bill.c.robe...@gmail.com]
>> > Sent: Monday, January 18, 2016 9:54 PM
>> > To: Inamdar Sharif
>> > Cc: seandroid-list@tycho.nsa.gov
>> > Subject: Re: avc denial while enabling zram
>> >
>> >
>> >
>> > Is that denial actually manifesting itself as some broken functionality?
>> >
>> > Also, why is fsck getting invoked on swap, especially one backed by
>> zram?
>> >
>> > On Jan 18, 2016 8:20 AM, "Inamdar Sharif" <isha...@nvidia.com> wrote:
>> >
>> > Hi Guys,
>> >
>> >
>> >
>> > I am facing the below avc denial while enabling zram.
>> >
>> > avc: denied { getattr } for pid=7545 comm="e2fsck"
>> > path="/dev/block/zram0" dev="tmpfs" ino=11973 scontext=u:r:fsck:s0
>> > tcontext=u:object_r:swap_block_device:s0 tclass=blk_file permissive=0
>> >
>> >
>> >
>> > I have labelled dev/block/zram0 as swap_block_device
>> >
>> > Also I have an entry in the fstab :
>> >
>> > /dev/block/zram0 none swap defaults
>> > zramsize=536870912
>> >
>> >
>> >
>> > But due to neverallow rule in fsck.te the above permission cannot be
>> granted.
>> >
>> > # fsck should never be run on these block devices
>> >
>> > neverallow fsck {
>> >
>> > boot_block_device
>> >
>> > frp_block_device
>> >
>> > metadata_block_device
>> >
>> > recovery_block_device
>> >
>> > root_block_device
>> >
>> > swap_block_device
>> >
>> > system_block_device
>> >
>> > vold_device
>> >
>> > }:blk_file no_rw_file_perms;
>> >
>> >
>> >
>> > So I think we have to remove swap_block_device from the neverallow. Any
>> suggestions??
>> >
>> >
>> >
>> > Thanks.
>> >
>> > ________________________________
>> >
>> > This email message is for the sole use of the intended recipient(s) and
>> may contain confidential information. Any unauthorized review, use,
>> disclosure or distribution is prohibited. If you are not the intended
>> recipient, please contact the sender by reply email and destroy all copies
>> of the original message.
>> >
>> > ________________________________
>> >
>> >
>> > _______________________________________________
>> > Seandroid-list mailing list
>> > Seandroid-list@tycho.nsa.gov
>> > To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
>> > To get help, send an email containing "help" to
>> seandroid-list-requ...@tycho.nsa.gov.
>>
>> _______________________________________________
>> Seandroid-list mailing list
>> Seandroid-list@tycho.nsa.gov
>> To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
>> To get help, send an email containing "help" to
>> seandroid-list-requ...@tycho.nsa.gov.
>>
>> _______________________________________________
>> Seandroid-list mailing list
>> Seandroid-list@tycho.nsa.gov
>> To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
>> To get help, send an email containing "help" to
>> seandroid-list-requ...@tycho.nsa.gov.
>
>
--
Respectfully,
William C Roberts
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
