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.
