I had a few minutes over lunch to test Jeff's suggestion:
I did a build with this patch:
-/dev/block/zram0 none swap defaults
zramsize=419430400
+/dev/block/zram0 none swap defaults
notrim,zramsize=419430400
Still see the message.
[ 255.716737] type=1400 audit(1451649711.930:15): avc: denied { getattr }
for pid=5013 comm="e2fsck" path="/dev/block/zram0" dev="tmpfs" ino=11433
scontext=u:r:fsck:s0 tcontext=u:object_r:swap_block_device:s0
tclass=blk_file permissive=0
I put the device into permissive mode and the only permission request I see
it making is getattr. I have no rules (verified with sesearch) that allow
fsck access to swap_block_device. So it does appear to be a single stat()
call somewhere, perhaps right where Jeff suggested earlier.
On Tue, Jan 19, 2016 at 12:41 PM, William Roberts <bill.c.robe...@gmail.com>
wrote:
>
>
> On Tue, Jan 19, 2016 at 12:26 PM, William Roberts <
> bill.c.robe...@gmail.com> wrote:
>
>>
>> On Jan 19, 2016 12:20 PM, "Jeffrey Vander Stoep" <je...@google.com>
>> wrote:
>> >
>> > Try adding notrim in your fstab. Trimming swap makes no sense.
>>
>> Does defaults include discard? I haven't looked.
>>
> Ok I see that notrim is a fs manager flag, not a mount option.
>
>
>>
>> >
>> > On Tue, Jan 19, 2016 at 9:31 AM William Roberts <
>> bill.c.robe...@gmail.com> wrote:
>> >>
>> >> 1. The no logging on the stat failure is consistent to what I am
>> seeing. So you might have the correct spot.
>> >> 2. The fstab entry: /dev/block/zram0 none
>> swap defaults zramsize=419430400
>> >>
>> >>
>> >> I wanted to run a test with fsck in permissive to see if it only
>> requests getattr, or if it requests more. The pattern of requests might help
>> >> deduce the area of code executing.
>> >>
>> >> On Tue, Jan 19, 2016 at 9:28 AM, Jeffrey Vander Stoep <
>> je...@google.com> wrote:
>> >>>
>> >>> Does your zram have the notrim option set in the fstab? e.g.
>> https://android.googlesource.com/device/htc/flounder/+/master/fstab.flounder#16
>> >>>
>> >>>
>> >>> On Tue, Jan 19, 2016 at 9:18 AM Jeffrey Vander Stoep <
>> je...@google.com> wrote:
>> >>>>
>> >>>> I wonder if
>> https://android.googlesource.com/platform/external/e2fsprogs/+/master/e2fsck/profile.c#270
>> is
>> the cause. It's fstat'ing every file in the directory to see if it exists.
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Tue, Jan 19, 2016 at 8:44 AM William Roberts <
>> bill.c.robe...@gmail.com> wrote:
>> >>>>>
>> >>>>> 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:
>> >>>>>> Ignore it. It's working as intended.
>> >>>>>> dontaudit it. Same as above but removes the denial
>> >>>>>> track down the source of the denial and fix.
>> >>>>>> 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
>> >>>>>
>> >>
>> >>
>> >>
>> >> --
>> >> Respectfully,
>> >>
>> >> William C Roberts
>> >>
>>
>>
>
>
> --
> Respectfully,
>
> William C Roberts
>
>
--
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.
