On 01/19/2016 11:00 AM, Inamdar Sharif 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??
Could be a vold-spawned fsck, but why it would be running fsck on a swap
partition I do not know. Would only expect it on vold-managed partitions.
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.
_______________________________________________
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.
