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.
