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 <[email protected] > <mailto:[email protected]>> 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)? 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.
