On 7 May 2018 at 23:29, Yongqin Liu <yongqin....@linaro.org> wrote:

>
>
> On 7 May 2018 at 22:41, Stephen Smalley <s...@tycho.nsa.gov> wrote:
>
>> On 05/07/2018 01:29 AM, Yongqin Liu wrote:
>> > @Sandeep,
>> > I see you submitted the change "Add label for kernel test files and
>> executables" here:
>> > https://android.googlesource.com/platform/system/sepolicy/+/
>> 34e35e9e9500608409920471dc05f12b9317338e
>> >
>> > So looped you here, maybe you have some suggestion on this problem.
>> >
>> >
>> > On 5 May 2018 at 01:02, Stephen Smalley <s...@tycho.nsa.gov <mailto:
>> s...@tycho.nsa.gov>> wrote:
>> >
>> >     On 05/04/2018 09:56 AM, Yongqin Liu wrote:
>> >     > Hi, All
>> >     >
>> >     > When I run "mkfs.ext2 /dev/block/loop7" with 4.14 kernel on AOSP
>> master build, i got the following  denials:
>> >     >
>> >     > [ 3004.028178] type=1400 audit(1525358655.127:5624): avc: denied
>> { read } for pid=2868 comm="loop7" path="/data/local/tmp/fstest/fstest.img"
>> dev="mmcblk0p10" ino=130561 scontext=u:r:kernel:s0
>> tcontext=u:object_r:shell_data_file:s0
>> >     > tclass=file permissive=0
>> >     >
>> >     >
>> >     > but not get such denials with 4.9 kernel.
>> >     >
>> >     > The only change is the kernel version, the userspace of Android
>> is the same.
>> >     >
>> >     > For details, please check the links here:
>> >     >
>> >     > 4.14-mkfs.ext2 https://pastebin.ubuntu.com/p/yBzz7TXjGy/ <
>> https://pastebin.ubuntu.com/p/yBzz7TXjGy/>
>> >     > 4.9-mkfs.ext2   https://pastebin.ubuntu.com/p/JCHYznxHww/ <
>> https://pastebin.ubuntu.com/p/JCHYznxHww/>
>> >     >
>> >     >
>> >     > I guess there is more strict check related to the mkfs operation
>> in kernel side,
>> >     > but I could not find out which operation yet.
>> >     > not sure if anyone knows any clues about this problem.
>> >     >
>> >     > Thanks in advance!
>> >     >
>> >     > BTW, mkfs.vfat does not have this problem with 4.14, mkfs.ext4
>> has the same problem.
>> >
>> >     I see the following in system/sepolicy/public/kernel.te:
>> >     # Allow reading loop device in update_engine_unittests. (b/28319454)
>> >     # and for LTP kernel tests (b/73220071)
>> >     userdebug_or_eng(`
>> >       allow kernel update_engine_data_file:file read;
>> >       allow kernel nativetest_data_file:file read;
>> >     ')
>> >
>> >     It seems like you could add another rule there for shell_data_file,
>> as long as it remains bracketed
>> >     by userdebug_or_eng().  This obviously is not something that should
>> happen on user builds.
>> >
>> >
>> > After changed to label the img file with nativetest_data_file, the
>> mkfs.ext2 command exit with 0, but still could see avc denials related to
>> write permission.
>> > and it caused the mount command next failed.
>> > When change to permissive mode, do not see the IO message in kernel log
>> for mkfs.ext2 command, and the mount command next could be run successfully.
>> > seems the mkfs.ext2 command will write something to the local .img file.
>> >
>> > I am thinking if we should allow write permission(like read) for kernel
>> on nativetest_data_file under userdebug_or_eng,
>> > but not sure if it's the right solution or there is any other better
>> solution.
>> >
>> > but considering this only happens with 4.14, but not with 4.9 kernel,
>> it might be better to understand what changed in the kernel side.
>> >
>> > Background:
>> > I am testing the VtsKernelLtp with android build, and found there are
>> failures passed when run under permissive mode.
>> > the instructions I run here are similar to the steps run by
>> the VtsKernelLtp failed tests cases.
>> >
>> > Following is the output for the commands and kernel message from the
>> serial console.
>> > #### commands under enforce mode ##############
>> > console:/data/local/tmp/ltp/tmp/tmpdir #dd if=/dev/zero of=fstest.img
>> bs=1M count=100                                  <
>> > 100+0 records in
>> > 100+0 records out
>> > 104857600 bytes (100 M) copied, 0.502641 s, 199 M/s
>> > console:/data/local/tmp/ltp/tmp/tmpdir # ls -Z fstest.img
>>
>> > u:object_r:nativetest_data_file:s0 fstest.img
>> > console:/data/local/tmp/ltp/tmp/tmpdir # losetup /dev/block/loop0
>> fstest.img
>> > console:/data/local/tmp/ltp/tmp/tmpdir # mkfs.ext2 /dev/block/loop0
>> > mke2fs 1.43.3 (04-Sep-2016)
>> > Discarding device blocks: done
>> > Creating filesystem with 102400 1k blocks and 25688 inodes
>> > Filesystem UUID: 7d0a8476-7beb-4423-af6d-63dc4f3fc5f4
>> > Superblock backups stored on blocks:
>> >         8193, 24577, 40961, 57345, 73729
>> >
>> > Allocating group tables: done
>> > Writing inode tables: done
>> > Writing superblocks and filesystem accounting information: [
>> 1902.539349] lo_write_bvec: 899 callbacks suppressed
>> > [ 1902.539355] loop: Write error at byte offset 0, length 4096.
>> > [ 1902.539837] type=1400 audit(1525526318.835:9173): avc: denied {
>> write } for comm="loop1" path="/data/local/tmp/ltp/tmp/tmpdir/fstest.img"
>> dev="mmcblk0p10" ino=133576 scontext=u:r:kernel:s0
>> tcontext=u:object_r:nativetest_data_fil
>> > e:s0 tclass=file permissive=0 duplicate messages suppressed
>> > [ 1902.539869] type=1400 audit(1525526458.879:10076): avc: denied {
>> write } for comm="loop0" path="/data/local/tmp/ltp/tmp/tmpdir/fstest.img"
>> dev="mmcblk0p10" ino=130248 scontext=u:r:kernel:s0
>> tcontext=u:object_r:nativetest_data_fi
>> > le:s0 tclass=file permissive=0
>> > [ 1902.598875] print_req_error: 899 callbacks suppressed
>> > [ 1902.598882] print_req_error: I/O error, dev loop0, sector 0
>> > [ 1902.598913] loop: Write error at byte offset 4096, length 4096.
>> > [ 1902.598941] loop: Write error at byte offset 8192, length 4096.
>> > [ 1902.598967] loop: Write error at byte offset 12288, length 4096.
>> > [ 1902.598999] loop: Write error at byte offset 16384, length 4096.
>> > [ 1902.599025] audit: audit_lost=9682 audit_rate_limit=5
>> audit_backlog_limit=64
>> > [ 1902.599029] audit: rate limit exceeded
>> > [ 1902.599035] loop: Write error at byte offset 20480, length 4096.
>> > [ 1902.599060] loop: Write error at byte offset 24576, length 4096.
>> > [ 1902.599085] loop: Write error at byte offset 28672, length 4096.
>> > [ 1902.599110] loop: Write error at byte offset 32768, length 4096.
>> > [ 1902.599135] loop: Write error at byte offset 36864, length 4096.
>> > [ 1902.674901] buffer_io_error: 899 callbacks suppressed
>> > [ 1902.674906] Buffer I/O error on dev loop0, logical block 0, lost
>> async page write
>> > [ 1902.687629] print_req_error: I/O error, dev loop0, sector 8
>> > [ 1902.693260] Buffer I/O error on dev loop0, logical block 1, lost
>> async page write
>> > [ 1902.700833] print_req_error: I/O error, dev loop0, sector 16
>> > [ 1902.706551] Buffer I/O error on dev loop0, logical block 2, lost
>> async page write
>> > [ 1902.714122] print_req_error: I/O error, dev loop0, sector 24
>> > [ 1902.719840] Buffer I/O error on dev loop0, logical block 3, lost
>> async page write
>> > [ 1902.727411] print_req_error: I/O error, dev loop0, sector 32
>> > [ 1902.733128] Buffer I/O error on dev loop0, logical block 4, lost
>> async page write
>> > [ 1902.740698] print_req_error: I/O error, dev loop0, sector 40
>> > [ 1902.746416] Buffer I/O error on dev loop0, logical block 5, lost
>> async page write
>> > [ 1902.753987] print_req_error: I/O error, dev loop0, sector 48
>> > [ 1902.759704] Buffer I/O error on dev loop0, logical block 6, lost
>> async page write
>> > [ 1902.767274] print_req_error: I/O error, dev loop0, sector 56
>> > [ 1902.772991] Buffer I/O error on dev loop0, logical block 7, lost
>> async page write
>> > [ 1902.780574] print_req_error: I/O error, dev loop0, sector 64
>> > [ 1902.786291] Buffer I/O error on dev loop0, logical block 8, lost
>> async page write
>> > [ 1902.793866] print_req_error: I/O error, dev loop0, sector 72
>> > [ 1902.799584] Buffer I/O error on dev loop0, logical block 9, lost
>> async page write
>> > done
>> >
>> > console:/data/local/tmp/ltp/tmp/tmpdir # echo $?
>> > 0
>> > console:/data/local/tmp/ltp/tmp/tmpdir # getenforce
>>
>> > Enforcing
>> > console:/data/local/tmp/ltp/tmp/tmpdir # mount -t ext2
>> /dev/block/loop0 mnt/
>> > mount: '/dev/block/loop0'->'mnt/': Invalid argument
>> > 1|console:/data/local/tmp/ltp/tmp/tmpdir #
>> >
>> > ##########change to permissive mode##########################
>> ###########################
>> >
>> > 1|console:/data/local/tmp/ltp/tmp/tmpdir # setenforce 0
>>
>> > [ 2208.705639] type=1400 audit(1525526458.939:10080): avc: denied {
>> write } for comm="loop0" path="/data/local/tmp/ltp/tmp/tmpdir/fstest.img"
>> dev="mmcblk0p10" ino=130248 scontext=u:r:kernel:s0
>> tcontext=u:object_r:nativetest_data_fi
>> > le:s0 tclass=file permissive=0 duplicate messages suppressed
>> > console:/data/local/tmp/ltp/tmp/tmpdir # [ 2208.735957] type=1404
>> audit(1525526765.047:10985): enforcing=0 old_enforcing=1 auid=4294967295
>> ses=4294967295
>> >
>> > console:/data/local/tmp/ltp/tmp/tmpdir # mkfs.ext2 /dev/block/loop0
>>
>> > mke2fs 1.43.3 (04-Sep-2016)
>> > Discarding device blocks: done
>> > Creating filesystem with 102400 1k blocks and 25688 inodes
>> > Filesystem UUID: 2f6a2235-0891-4827-8010-703e784425d0
>> > Superblock backups stored on blocks:
>> >         8193, 24577, 40961, 57345, 73729
>> >
>> > Allocating group tables: done
>> > Writing inode tables: done
>> > Writing superblocks and filesystem accounting information: [
>> 2223.524365] type=1404 audit(1525526765.047:10985): enforcing=0
>> old_enforcing=1 auid=4294967295 ses=4294967295
>> > [ 2223.534585] type=1400 audit(1525526779.867:10986): avc: denied {
>> write } for comm="loop0" path="/data/local/tmp/ltp/tmp/tmpdir/fstest.img"
>> dev="mmcblk0p10" ino=130248 scontext=u:r:kernel:s0
>> tcontext=u:object_r:nativetest_data_fi
>> > le:s0 tclass=file permissive=1
>> > done
>> >
>> > console:/data/local/tmp/ltp/tmp/tmpdir # echo $?
>>
>> > 0
>> > console:/data/local/tmp/ltp/tmp/tmpdir # mount -t ext2
>> /dev/block/loop0 mnt/
>> > [ 2257.524735] EXT4-fs (loop0): mounting ext2 file system using the
>> ext4 subsystem
>> > [ 2257.540576] EXT4-fs (loop0): mounted filesystem without journal.
>> Opts: (null)
>> > console:/data/local/tmp/ltp/tmp/tmpdir # echo $?
>> > 0
>> > console:/data/local/tmp/ltp/tmp/tmpdir #
>>
>> In what context are you running these commands (e.g. id -Z output from
>> your console shell)?
>>
>> I run the commands as root with userdebug build, after run su command.
>
>
>> It makes sense that you would need read and write permissions to the
>> underlying storage.  I am a little puzzled
>> as to why it is showing up as a denial on a scontext of u:r:kernel:s0
>> unless your console shell is running in
>> the kernel's context.
>>
>> I don't know what changed in the kernel but it seems correct that it is
>> now making these checks.  Possibly
>> this was part of the changes to support mounting of filesystems from user
>> namespaces, to ensure that the
>> process was truly authorized to read/write the underlying storage.
>>
>
> I think I found the change, it the change here:
> https://android.googlesource.com/kernel/hikey-linaro/+/
> abbb65899aecfc97bda64b6816d1e501754cfe1f%5E%21/#F3
>
> In the change, it calls do_iter_write in vfs_iter_write, and that makes
> the vfs_iter_write call rw_verify_area in directly,
> https://android.googlesource.com/kernel/hikey-linaro/+/
> android-hikey-linaro-4.14/fs/read_write.c#938
>
> which calls security_file_permission for permission check.
>
> While the 4.9 vfs_iter_write does not security_file_permission in it's
> implementation here:
> https://android.googlesource.com/kernel/hikey-linaro/+/
> android-hikey-linaro-4.9/fs/read_write.c
>
> I do not verify my thought with any build yet, but I think if I reverted
> the above change for 4.14 kernel, then the denials will go.
>
Verified with the change
https://android.googlesource.com/kernel/hikey-linaro/+/abbb65899aecfc97bda64b6816d1e501754cfe1f%5E%21/#F3
 reverted,
and no similar avc denials reported again. And the original failed VTS test
cases passed now.

Need to check on how to update the sepolicy rules on userspace side.

-- 
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android

Reply via email to