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