[prev in list] [next in list] [prev in thread] [next in thread]
List: seandroid-list
Subject: Re: avc denial while enabling zram
From: Jeffrey Vander Stoep <jeffv () google ! com>
Date: 2016-01-21 23:31:37
Message-ID: CABXk95BENdhJLjFQ0W9GxP_DPAok=0e52BUJxQPuVXeetaQ44A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
The stat call is coming from the is_swap_device function in libext2fs:
https://android.googlesource.com/platform/external/e2fsprogs/+/android-6.0.1_r5/lib/ext2fs/ismounted.c#323
It should be allowed
Up for review on AOSP: https://android-review.googlesource.com/197750
On Tue, Jan 19, 2016 at 1:47 PM William Roberts <bill.c.roberts@gmail.com>
wrote:
> 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.roberts@gmail.com> wrote:
>
> >
> >
> > On Tue, Jan 19, 2016 at 12:26 PM, William Roberts <
> > bill.c.roberts@gmail.com> wrote:
> >
> > >
> > > On Jan 19, 2016 12:20 PM, "Jeffrey Vander Stoep" <jeffv@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.roberts@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 <
> > > jeffv@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 <
> > > jeffv@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.roberts@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 <
> > > jeffv@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 <
> > > isharif@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-bounces@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.roberts@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-bounces@tycho.nsa.gov] On Behalf Of William Roberts
> > > > > > > > > > Sent: Monday, January 18, 2016 8:53 AM
> > > > > > > > > > To: Inamdar Sharif <isharif@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" <isharif@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.roberts@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" <isharif@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-leave@tycho.nsa.gov.
> > > > > > > > > > > To get help, send an email containing "help" to
> > > Seandroid-list-request@tycho.nsa.gov.
> > > > > > > > > >
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Seandroid-list mailing list
> > > > > > > > > > Seandroid-list@tycho.nsa.gov
> > > > > > > > > > To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov
> > > .
> > > > > > > > > > To get help, send an email containing "help" to
> > > Seandroid-list-request@tycho.nsa.gov.
> > > > > > > > > >
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Seandroid-list mailing list
> > > > > > > > > > Seandroid-list@tycho.nsa.gov
> > > > > > > > > > To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov
> > > .
> > > > > > > > > > To get help, send an email containing "help" to
> > > Seandroid-list-request@tycho.nsa.gov.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Respectfully,
> > > > > > > >
> > > > > > > > William C Roberts
> > > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Respectfully,
> > > > >
> > > > > William C Roberts
> > > > >
> > >
> > >
> >
> >
> > --
> > Respectfully,
> >
> > William C Roberts
> >
> >
>
>
> --
> Respectfully,
>
> William C Roberts
>
>
[Attachment #5 (text/html)]
<div dir="ltr">The stat call is coming from the is_swap_device function in \
libext2fs: <a href="https://android.googlesource.com/platform/external/e2fsprogs/+/android-6.0.1_r5/lib/ext2fs/ismounted.c#323" \
target="_blank">https://android.googlesource.com/platform/external/e2fsprogs/+/android-6.0.1_r5/lib/ext2fs/ismounted.c#323</a><br><br>It \
should be allowed<br><br>Up for review on AOSP: <a \
href="https://android-review.googlesource.com/197750" \
target="_blank">https://android-review.googlesource.com/197750</a><div \
dir="ltr"><div><br></div><div><div class="gmail_quote"><div dir="ltr">On Tue, Jan 19, \
2016 at 1:47 PM William Roberts <<a href="mailto:bill.c.roberts@gmail.com" \
target="_blank">bill.c.roberts@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div>I had a few minutes over lunch to test \
Jeff's suggestion:</div><div><br></div><div>I did a build with this \
patch:</div><div><div>-/dev/block/zram0 none \
swap defaults \
zramsize=419430400</div><div>+/dev/block/zram0 \
none swap defaults \
notrim,zramsize=419430400</div></div><div><br></div><div><br></div><div>Still see the \
message.</div><div><div>[ 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</div></div><div><br></div><div>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.</div></div><div dir="ltr"><div><br></div><div><br></div><div><br></div><div \
class="gmail_extra"><div class="gmail_quote">On Tue, Jan 19, 2016 at 12:41 PM, \
William Roberts <span dir="ltr"><<a href="mailto:bill.c.roberts@gmail.com" \
target="_blank">bill.c.roberts@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Jan \
19, 2016 at 12:26 PM, William Roberts <span dir="ltr"><<a \
href="mailto:bill.c.roberts@gmail.com" \
target="_blank">bill.c.roberts@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><p \
dir="ltr"><br> On Jan 19, 2016 12:20 PM, "Jeffrey Vander Stoep" <<a \
href="mailto:jeffv@google.com" target="_blank">jeffv@google.com</a>> wrote:<br> \
><br> > Try adding notrim in your fstab. Trimming swap makes no sense.</p>
</span><p dir="ltr">Does defaults include discard? I haven't \
looked.</p></blockquote></span><div>Ok I see that notrim is a fs manager flag, not a \
mount option.</div><div><div><div> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><br>
><br>
> On Tue, Jan 19, 2016 at 9:31 AM William Roberts <<a \
href="mailto:bill.c.roberts@gmail.com" \
target="_blank">bill.c.roberts@gmail.com</a>> wrote:<br> >><br>
>> 1. The no logging on the stat failure is consistent to what I am seeing. So \
you might have the correct spot.<br> >> 2. The fstab entry: /dev/block/zram0 \
none swap defaults \
zramsize=419430400<br> >><br>
>><br>
>> 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<br> >> \
deduce the area of code executing.<br> >><br>
>> On Tue, Jan 19, 2016 at 9:28 AM, Jeffrey Vander Stoep <<a \
href="mailto:jeffv@google.com" target="_blank">jeffv@google.com</a>> wrote:<br> \
>>><br> >>> Does your zram have the notrim option set in the \
fstab? e.g. <a href="https://android.googlesource.com/device/htc/flounder/+/master/fstab.flounder#16" \
target="_blank">https://android.googlesource.com/device/htc/flounder/+/master/fstab.flounder#16</a><br>
>>><br>
>>><br>
>>> On Tue, Jan 19, 2016 at 9:18 AM Jeffrey Vander Stoep <<a \
href="mailto:jeffv@google.com" target="_blank">jeffv@google.com</a>> wrote:<br> \
>>>><br> >>>> I wonder if <a \
href="https://android.googlesource.com/platform/external/e2fsprogs/+/master/e2fsck/profile.c#270" \
target="_blank">https://android.googlesource.com/platform/external/e2fsprogs/+/master/e2fsck/profile.c#270</a> \
is the cause. It's fstat'ing every file in the directory to see if it \
exists.<br> >>>><br>
>>>><br>
>>>><br>
>>>> On Tue, Jan 19, 2016 at 8:44 AM William Roberts <<a \
href="mailto:bill.c.roberts@gmail.com" \
target="_blank">bill.c.roberts@gmail.com</a>> wrote:<br> >>>>><br>
>>>>> I was able to reproduce this on a device with sdcard \
support.<br> >>>>><br>
>>>>> [ 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<br> \
>>>>><br> >>>>> It works for us without this rule. This \
is likely related to vold as Stephen pointed out calling the Format and Check \
routines (conjecture).<br> >>>>><br>
>>>>> dmesg:<br>
>>>>> [ 9.405740] fs_mgr: Running /system/bin/e2fsck on \
/dev/block/by-name/data<br> >>>>> [ 9.719493] e2fsck: e2fsck \
1.42.9 (28-Dec-2013)<br> >>>>> [ 9.719578] e2fsck: data: clean, \
1177/262944 files, 48464/1050112 blocks<br> >>>>> [ 9.786987] \
fs_mgr: Running /system/bin/e2fsck on /dev/block/by-name/cache<br> \
>>>>> [ 9.817792] e2fsck: e2fsck 1.42.9 (28-Dec-2013)<br> \
>>>>> [ 9.817867] e2fsck: cache: clean, 16/6400 files, 1444/25600 \
blocks<br> >>>>><br>
>>>>> logcat:<br>
>>>>> 01-16 05:56:01.577 168 191 V vold : \
/system/bin/fsck_msdos<br> >>>>> 01-16 05:56:25.<a \
href="tel:902%20%C2%A0%20674%20%C2%A01620" value="+19026741620" target="_blank">902 \
674 1620</a> I BootReceiver: Checking for fsck errors<br> >>>>> \
01-16 05:58:07.832 168 191 D Vold : Running /system/bin/e2fsck on \
/dev/block/dm-1<br> >>>>> 01-16 05:58:07.832 168 191 V vold \
: /system/bin/e2fsck<br> >>>>> 01-16 05:58:07.940 168 191 I \
e2fsck : e2fsck 1.42.9 (28-Dec-2013)<br> >>>>> 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<br> >>>>> 01-16 05:58:07.995 168 191 I e2fsck : \
/dev/block/dm-1: clean, 11/485760 files, 34812/1941243 blocks<br> \
>>>>><br> >>>>><br>
>>>>> 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<br> >>>>> and look into whats causing this. I don't really \
have time to debug this is an entirety at this point in time.<br> \
>>>>><br> >>>>> Bill<br>
>>>>><br>
>>>>> On Tue, Jan 19, 2016 at 8:24 AM, Jeffrey Vander Stoep <<a \
href="mailto:jeffv@google.com" target="_blank">jeffv@google.com</a>> wrote:<br> \
>>>>>><br> >>>>>> Some options:<br>
>>>>>> Ignore it. It's working as intended.<br>
>>>>>> dontaudit it. Same as above but removes the denial<br>
>>>>>> track down the source of the denial and fix.<br>
>>>>>> File a bug against AOSP.<br>
>>>>>> On Tue, Jan 19, 2016 at 8:12 AM Inamdar Sharif <<a \
href="mailto:isharif@nvidia.com" target="_blank">isharif@nvidia.com</a>> \
wrote:<br> >>>>>>><br>
>>>>>>> Checked init.rc as well, that's perfectly alright.<br>
>>>>>>><br>
>>>>>>> This avc I am facing while formatting the sdcard as \
internal storage. Any more ideas??<br> >>>>>>><br>
>>>>>>> Thanks.<br>
>>>>>>><br>
>>>>>>> -----Original Message-----<br>
>>>>>>> From: Seandroid-list [mailto:<a \
href="mailto:seandroid-list-bounces@tycho.nsa.gov" \
target="_blank">seandroid-list-bounces@tycho.nsa.gov</a>] On Behalf Of Inamdar \
Sharif<br> >>>>>>> Sent: Tuesday, January 19, 2016 12:25 PM<br>
>>>>>>> To: Roberts, William C; William Roberts<br>
>>>>>>> Cc: <a href="mailto:seandroid-list@tycho.nsa.gov" \
target="_blank">seandroid-list@tycho.nsa.gov</a><br> >>>>>>> \
Subject: RE: avc denial while enabling zram<br> >>>>>>><br>
>>>>>>> Yes we do have the same settings from SELinux POV.<br>
>>>>>>> We have the same code as the AOSP an no more additional \
changes on top of it.<br> >>>>>>><br>
>>>>>>> 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.<br> >>>>>>><br>
>>>>>>> Thanks.<br>
>>>>>>><br>
>>>>>>> -----Original Message-----<br>
>>>>>>> From: Roberts, William C [mailto:<a \
href="mailto:william.c.roberts@intel.com" \
target="_blank">william.c.roberts@intel.com</a>]<br> >>>>>>> \
Sent: Tuesday, January 19, 2016 12:50 AM<br> >>>>>>> To: William \
Roberts; Inamdar Sharif<br> >>>>>>> Cc: <a \
href="mailto:seandroid-list@tycho.nsa.gov" \
target="_blank">seandroid-list@tycho.nsa.gov</a><br> >>>>>>> \
Subject: RE: avc denial while enabling zram<br> >>>>>>><br>
>>>>>>> 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.<br> \
>>>>>>><br> >>>>>>> file_contexts:1:# ZRam \
device configured as swap space<br> >>>>>>> \
file_contexts:2:/dev/block/zram0 u:object_r:swap_block_device:s0<br> \
>>>>>>><br> >>>>>>> vold.te:allow vold \
swap_block_device:blk_file getattr;<br> >>>>>>><br>
>>>>>>> We never had to allow any access from fsck. I see no \
dontaudits, so perhaps were just ignoring the audit messages.<br> \
>>>>>>><br> >>>>>>> Bill<br>
>>>>>>><br>
>>>>>>> From: Seandroid-list [mailto:<a \
href="mailto:seandroid-list-bounces@tycho.nsa.gov" \
target="_blank">seandroid-list-bounces@tycho.nsa.gov</a>] On Behalf Of William \
Roberts<br> >>>>>>> Sent: Monday, January 18, 2016 8:53 AM<br>
>>>>>>> To: Inamdar Sharif <<a \
href="mailto:isharif@nvidia.com" target="_blank">isharif@nvidia.com</a>><br> \
>>>>>>> Cc: <a href="mailto:seandroid-list@tycho.nsa.gov" \
target="_blank">seandroid-list@tycho.nsa.gov</a><br> >>>>>>> \
Subject: RE: avc denial while enabling zram<br> >>>>>>><br>
>>>>>>> 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.<br> >>>>>>> On Jan \
18, 2016 8:41 AM, "Inamdar Sharif" <<a href="mailto:isharif@nvidia.com" \
target="_blank">isharif@nvidia.com</a>> wrote:<br> >>>>>>> \
><br> >>>>>>> > >>Is that denial actually \
manifesting itself as some broken functionality?<br> >>>>>>> \
><br> >>>>>>> > As such it is not breaking anything. But \
this is seen while formatting sdcard as internal storage.<br> \
>>>>>>> ><br> >>>>>>> > <br>
>>>>>>> ><br>
>>>>>>> > Also, why is fsck getting invoked on swap, \
especially one backed by zram?<br> >>>>>>> ><br>
>>>>>>> > Not sure about this but got something from the \
commit message which says that we don't have swap device on AOSP.<br> \
>>>>>>> ><br> >>>>>>> > <br>
>>>>>>> ><br>
>>>>>>> > <snip><br>
>>>>>>> ><br>
>>>>>>> > e2fsck is invoked on any partitions marked with the \
check mount<br> >>>>>>> ><br>
>>>>>>> > option in the fstab file, typically userdata and \
cache but never<br> >>>>>>> ><br>
>>>>>>> > system. We allow it to read/write the \
userdata_block_device and<br> >>>>>>> ><br>
>>>>>>> > cache_block_device types but also allow it to \
read/write the default<br> >>>>>>> ><br>
>>>>>>> > block_device type until we can get the more \
specific types assigned<br> >>>>>>> ><br>
>>>>>>> > in all of the device-specific policies.<br>
>>>>>>> ><br>
>>>>>>> > <br>
>>>>>>> ><br>
>>>>>>> > mkswap is invoked on any swap partition defined in \
the fstab file.<br> >>>>>>> ><br>
>>>>>>> > We introduce a new swap_block_device type for this \
purpose, to be<br> >>>>>>> ><br>
>>>>>>> > assigned to any such block devices in the \
device-specific policies,<br> >>>>>>> ><br>
>>>>>>> > and only allow it to read/write such block devices. \
As there seem to<br> >>>>>>> > be<br>
>>>>>>> ><br>
>>>>>>> > no devices in AOSP with swap partitions in their \
fstab files, this<br> >>>>>>> > does<br>
>>>>>>> ><br>
>>>>>>> > not appear to risk any breakage for existing \
devices.<br> >>>>>>> ><br>
>>>>>>> > </snip><br>
>>>>>>> ><br>
>>>>>>> > <br>
>>>>>>> ><br>
>>>>>>> > Thanks.<br>
>>>>>>> ><br>
>>>>>>> > <br>
>>>>>>> ><br>
>>>>>>> > From: William Roberts [mailto:<a \
href="mailto:bill.c.roberts@gmail.com" \
target="_blank">bill.c.roberts@gmail.com</a>]<br> >>>>>>> > \
Sent: Monday, January 18, 2016 9:54 PM<br> >>>>>>> > To: \
Inamdar Sharif<br> >>>>>>> > Cc: <a \
href="mailto:seandroid-list@tycho.nsa.gov" \
target="_blank">seandroid-list@tycho.nsa.gov</a><br> >>>>>>> \
> Subject: Re: avc denial while enabling zram<br> >>>>>>> \
><br> >>>>>>> > <br>
>>>>>>> ><br>
>>>>>>> > Is that denial actually manifesting itself as some \
broken functionality?<br> >>>>>>> ><br>
>>>>>>> > Also, why is fsck getting invoked on swap, \
especially one backed by zram?<br> >>>>>>> ><br>
>>>>>>> > On Jan 18, 2016 8:20 AM, "Inamdar Sharif" \
<<a href="mailto:isharif@nvidia.com" target="_blank">isharif@nvidia.com</a>> \
wrote:<br> >>>>>>> ><br>
>>>>>>> > Hi Guys,<br>
>>>>>>> ><br>
>>>>>>> > <br>
>>>>>>> ><br>
>>>>>>> > I am facing the below avc denial while enabling \
zram.<br> >>>>>>> ><br>
>>>>>>> > avc: denied { getattr } for pid=7545 \
comm="e2fsck" <br> >>>>>>> > \
path="/dev/block/zram0" dev="tmpfs" ino=11973 \
scontext=u:r:fsck:s0 <br> >>>>>>> > \
tcontext=u:object_r:swap_block_device:s0 tclass=blk_file permissive=0<br> \
>>>>>>> ><br> >>>>>>> > <br>
>>>>>>> ><br>
>>>>>>> > I have labelled dev/block/zram0 as \
swap_block_device<br> >>>>>>> ><br>
>>>>>>> > Also I have an entry in the fstab :<br>
>>>>>>> ><br>
>>>>>>> > /dev/block/zram0 none \
swap defaults <br> >>>>>>> > \
zramsize=536870912<br> >>>>>>> ><br>
>>>>>>> > <br>
>>>>>>> ><br>
>>>>>>> > But due to neverallow rule in fsck.te the above \
permission cannot be granted.<br> >>>>>>> ><br>
>>>>>>> > # fsck should never be run on these block \
devices<br> >>>>>>> ><br>
>>>>>>> > neverallow fsck {<br>
>>>>>>> ><br>
>>>>>>> > boot_block_device<br>
>>>>>>> ><br>
>>>>>>> > frp_block_device<br>
>>>>>>> ><br>
>>>>>>> > metadata_block_device<br>
>>>>>>> ><br>
>>>>>>> > recovery_block_device<br>
>>>>>>> ><br>
>>>>>>> > root_block_device<br>
>>>>>>> ><br>
>>>>>>> > swap_block_device<br>
>>>>>>> ><br>
>>>>>>> > system_block_device<br>
>>>>>>> ><br>
>>>>>>> > vold_device<br>
>>>>>>> ><br>
>>>>>>> > }:blk_file no_rw_file_perms;<br>
>>>>>>> ><br>
>>>>>>> > <br>
>>>>>>> ><br>
>>>>>>> > So I think we have to remove swap_block_device from \
the neverallow. Any suggestions??<br> >>>>>>> ><br>
>>>>>>> > <br>
>>>>>>> ><br>
>>>>>>> > Thanks.<br>
>>>>>>> ><br>
>>>>>>> > ________________________________<br>
>>>>>>> ><br>
>>>>>>> > 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.<br> >>>>>>> ><br>
>>>>>>> > ________________________________<br>
>>>>>>> ><br>
>>>>>>> ><br>
>>>>>>> > _______________________________________________<br>
>>>>>>> > Seandroid-list mailing list<br>
>>>>>>> > <a href="mailto:Seandroid-list@tycho.nsa.gov" \
target="_blank">Seandroid-list@tycho.nsa.gov</a><br> >>>>>>> \
> To unsubscribe, send email to <a \
href="mailto:Seandroid-list-leave@tycho.nsa.gov" \
target="_blank">Seandroid-list-leave@tycho.nsa.gov</a>.<br> \
>>>>>>> > To get help, send an email containing \
"help" to <a href="mailto:Seandroid-list-request@tycho.nsa.gov" \
target="_blank">Seandroid-list-request@tycho.nsa.gov</a>.<br> \
>>>>>>><br> >>>>>>> \
_______________________________________________<br> >>>>>>> \
Seandroid-list mailing list<br> >>>>>>> <a \
href="mailto:Seandroid-list@tycho.nsa.gov" \
target="_blank">Seandroid-list@tycho.nsa.gov</a><br> >>>>>>> To \
unsubscribe, send email to <a href="mailto:Seandroid-list-leave@tycho.nsa.gov" \
target="_blank">Seandroid-list-leave@tycho.nsa.gov</a>.<br> \
>>>>>>> To get help, send an email containing "help" \
to <a href="mailto:Seandroid-list-request@tycho.nsa.gov" \
target="_blank">Seandroid-list-request@tycho.nsa.gov</a>.<br> \
>>>>>>><br> >>>>>>> \
_______________________________________________<br> >>>>>>> \
Seandroid-list mailing list<br> >>>>>>> <a \
href="mailto:Seandroid-list@tycho.nsa.gov" \
target="_blank">Seandroid-list@tycho.nsa.gov</a><br> >>>>>>> To \
unsubscribe, send email to <a href="mailto:Seandroid-list-leave@tycho.nsa.gov" \
target="_blank">Seandroid-list-leave@tycho.nsa.gov</a>.<br> \
>>>>>>> To get help, send an email containing "help" \
to <a href="mailto:Seandroid-list-request@tycho.nsa.gov" \
target="_blank">Seandroid-list-request@tycho.nsa.gov</a>.<br> \
>>>>><br> >>>>><br>
>>>>><br>
>>>>><br>
>>>>> -- <br>
>>>>> Respectfully,<br>
>>>>><br>
>>>>> William C Roberts<br>
>>>>><br>
>><br>
>><br>
>><br>
>> -- <br>
>> Respectfully,<br>
>><br>
>> William C Roberts<br>
>><br>
</div></div><p></p>
</blockquote></div></div></div><div><div><br><br clear="all"><div><br></div>-- \
<br><div>Respectfully,<br><br>William C Roberts<br><br></div> \
</div></div></div></div> </blockquote></div><br><br clear="all"><div><br></div>-- \
<br><div>Respectfully,<br><br>William C Roberts<br><br></div> \
</div></div></blockquote></div></div></div></div>
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic