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. but obviously, the 4.14 side is the correct implementation I think. mkfs.ext2 needs to write something to the img file. guess mkfs.vfat needs to do the similar check too -- Best Regards, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android
