Re: mkfs.ext2 /dev/block/loop7 got avc denials with 4.14 kernel but not with 4.9 kernel
Submitted a temporary workaround on selinux rules here: https://android-review.googlesource.com/c/platform/system/sepolicy/+/682121 in case the re-order of events has any problem. Thanks, Yongqin Liu On 8 May 2018 at 14:47, Yongqin Liu <yongqin@linaro.org> wrote: > > > On 8 May 2018 at 12:15, Sandeep Patil <sspa...@google.com> wrote: > >> >> >> On Mon, May 7, 2018 at 10:46 AM Stephen Smalley <s...@tycho.nsa.gov> >> wrote: >> >>> On 05/07/2018 01:17 PM, Yongqin Liu wrote: >>> > >>> > >>> > On 8 May 2018 at 00:55, Stephen Smalley <s...@tycho.nsa.gov >> s...@tycho.nsa.gov>> wrote: >>> > >>> > On 05/07/2018 12:51 PM, Stephen Smalley wrote: >>> > > On 05/07/2018 12:30 PM, Yongqin Liu wrote: >>> > >> I run the commands as root with userdebug build, after run >>> su command. >>> > > >>> > > Can you run id -Z before and after running su? I'm trying to >>> understand why the scontext is u:r:kernel:s0 instead of e.g. u:r:shell:s0 >>> (regular shell) or u:r:su:s0 (su shell). >>> > >>> > h01:04:28 liuyq: ~$ adb shell >>> > hikey:/ $ id >>> > uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input) >>> ,1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001( >>> net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) >>> context=u:r:shell:s0 >>> > hikey:/ $ su >>> > hikey:/ # id >>> > uid=0(root) gid=0(root) groups=0(root),1004(input),100 >>> 7(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_ >>> bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) >>> context=u:r:su:s0 >>> > hikey:/ # ^D >>> > hikey:/ $ ^D >>> > 01:05:52 liuyq: ~$ adb shell >>> > hikey:/ $ >>> > hikey:/ $ id -Z >>> > context=u:r:shell:s0 >>> > hikey:/ $ su >>> > hikey:/ # id -Z >>> > context=u:r:su:s0 >>> > hikey:/ # >>> > >>> > >>> > >>> > Is it because it is a console rather than adb and there is no >>> domain transition defined for shell execution from the console? Should >>> there be a domain_auto_trans(kernel, shell_exec, shell) rule in policy? >>> > >>> > Both running it from the serial console after su, or the via vts with >>> adb shell(after adb root), will report kernel scontext domain. >>> > >>> > >>> > Actually, we don't allow kernel domain to execute anything other >>> than init, so I don't understand how you got a shell running in kernel >>> domain (if that is in fact what you did). >>> > >>> > >>> > it's what i want to be clear too. >>> >>> Ok, the implication is that the actual write request is happening from a >>> kernel thread, not in the context of the process that is performing the >>> mkfs command, e.g. the write is deferred to a work queue or similar >>> mechanism. If so, then there isn't much point in performing the check at >>> all, because it will always be from the kernel domain regardless of the >>> userspace originator. >>> >>> I'm not sure that moving the security_file_permission() calls into >>> rw_verify_area() was a good idea since a userspace permissions check is >>> logically different than the other kinds of validation being performed >>> there. However, I think it >>> was motivated by the fact that originally all callers of >>> rw_verify_area() were also performing a security_file_permission() call, >>> and to help ensure that no future read/write interfaces bypassed the >>> security check. >>> >>> The underlying hook function, selinux_file_permission(), only performs a >>> permission check if something has changed since the checks performed at >>> open time, e.g. the current process' sid differs from that of the opener, >>> the inode SID has changed, or the policy has changed. In this case, I >>> assume it is because the writer is running in the kernel domain whereas the >>> opener was in the domain of the process that invoked mkfs, e.g. su. >>> >>> The near term fix is to simply allow it for the kernel domain under >>> userdebug_or_eng(). >> >> >> ... or simply re-order the events as ... >> >> 1. create a file >> 2. format it with mkfs.extN >> 3. .. then as
Re: mkfs.ext2 /dev/block/loop7 got avc denials with 4.14 kernel but not with 4.9 kernel
On 8 May 2018 at 00:55, Stephen Smalley <s...@tycho.nsa.gov> wrote: > On 05/07/2018 12:51 PM, Stephen Smalley wrote: > > On 05/07/2018 12:30 PM, Yongqin Liu wrote: > >> I run the commands as root with userdebug build, after run su > command. > > > > Can you run id -Z before and after running su? I'm trying to understand > why the scontext is u:r:kernel:s0 instead of e.g. u:r:shell:s0 (regular > shell) or u:r:su:s0 (su shell). h01:04:28 liuyq: ~$ adb shell hikey:/ $ id uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) context=u:r:shell:s0 hikey:/ $ su hikey:/ # id uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) context=u:r:su:s0 hikey:/ # ^D hikey:/ $ ^D 01:05:52 liuyq: ~$ adb shell hikey:/ $ hikey:/ $ id -Z context=u:r:shell:s0 hikey:/ $ su hikey:/ # id -Z context=u:r:su:s0 hikey:/ # > Is it because it is a console rather than adb and there is no domain > transition defined for shell execution from the console? Should there be a > domain_auto_trans(kernel, shell_exec, shell) rule in policy? > > Both running it from the serial console after su, or the via vts with adb shell(after adb root), will report kernel scontext domain. Actually, we don't allow kernel domain to execute anything other than init, > so I don't understand how you got a shell running in kernel domain (if that > is in fact what you did). > it's what i want to be clear too. Thanks, Yongqin Liu > > > > >> > >> > >> 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 < > 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 < > 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 <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/+/abbb65899aecfc97bda64b6816d1e5 > 01754cfe1f%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. > > > > Just make sure you wrap it with userdebug_or_eng() so it doesn't get > included in user builds. > > > > -- Best Regards, Yongqin Liu --- #mailing list linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android
Re: mkfs.ext2 /dev/block/loop7 got avc denials with 4.14 kernel but not with 4.9 kernel
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 > 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
Re: mkfs.ext2 /dev/block/loop7 got avc denials with 4.14 kernel but not with 4.9 kernel
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 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-63dc4f3f
Re: mkfs.ext2 /dev/block/loop7 got avc denials with 4.14 kernel but not with 4.9 kernel
@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> 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/
> > 4.9-mkfs.ext2 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:
mkfs.ext2 /dev/block/loop7 got avc denials with 4.14 kernel but not with 4.9 kernel
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/
4.9-mkfs.ext2 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.
--
Best Regards,
Yongqin Liu
---
#mailing list
linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
Re: ioctlcmd=7704 denied on unix_stream_socket for surfaceflinger and system_server domain
Thanks all! With the fix here: https://android-review.googlesource.com/#/c/198885/4/libs/binder/Parcel.cpp The problem fixed. On 13 July 2016 at 13:13, Jeffrey Vander Stoep <je...@google.com> wrote: > Ahh that's what is was. I knew their was something goofy about it that >> drove me nuts ;-p. >> >> You should update that print out. >> > > Not the first time you've requested that :) > > https://www.mail-archive.com/seandroid-list@tycho.nsa.gov/msg02416.html > > I was waiting to include it with a follow-on patchset, but that never > occurred. I'll add it to the TODO list. > -- Best Regards, Yongqin Liu --- #mailing list linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android ___ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
Re: ioctlcmd=7704 denied on unix_stream_socket for surfaceflinger and system_server domain
Hi, Jeffrey
On 13 July 2016 at 12:38, Jeffrey Vander Stoep <je...@google.com> wrote:
> No it's hex. Should have the 0x in front of it (but doesn't). Definitely
> my bad :(
>
> Looks like android-6.0.1_r55 has the patch I referred to. Yongqin, do you
> have repro steps?
>
I did not apply that manually.
And I just checked the frameworks/native project, the android-6.0.1_r55 tag
seems not have that fix.
Will apply that fix manually and check the result.
> On Tue, Jul 12, 2016 at 9:29 PM William Roberts <bill.c.robe...@gmail.com>
> wrote:
>
>>
>> On Jul 12, 2016 21:20, "Jeffrey Vander Stoep" <je...@google.com> wrote:
>> >
>> > Hi Yongqin,
>> >
>> > Looks like a process is indiscriminately
>> calling ashmem_get_size_region() (ioctl number 7704=ASHMEM_GET_SIZE) on a
>> unix socket. This is a bug and should not be allowed. The selinux denial is
>> working as intended.
>> >
>> > A similar bug was fixed here:
>> >
>> https://android-review.googlesource.com/#/c/198885/4/libs/binder/Parcel.cpp
>> >
>> > Does your tree include this patch?
>> >
>> > On Tue, Jul 12, 2016 at 8:43 PM YongQin Liu <yongqin@linaro.org>
>> wrote:
>> >>
>> >> Hi, All
>> >>
>> >> When I update to use tag android-6.0.1_r55, I got following avc
>> denials during the boot up:
>> >>
>> >> avc: denied { ioctl } for pid=177 comm="Binder_2"
>> path="socket:[10083]" dev="sockfs" ino=10083 ioctlcmd=7704
>> scontext=u:r:surfaceflinger:s0 tcontext=u:r:surfaceflinger:s0
>> tclass=unix_stream_socket permissive=0
>> >>
>> >> and
>> >> avc: denied { ioctl } for pid=465 comm="Binder_1"
>> path="socket:[14454]" dev="sockfs" ino=14454 ioctlcmd=7704
>> scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0
>> tclass=unix_stream_socket permissive=0
>> >>
>> >>
>> >> With following rules I can make the denials disappeared:
>> >> 11:29:17 liuyq: hikey$ git diff --staged
>> >> diff --git a/sepolicy/ioctl_macros b/sepolicy/ioctl_macros
>> >> new file mode 100644
>> >> index 000..398976c
>> >> --- /dev/null
>> >> +++ b/sepolicy/ioctl_macros
>> >> @@ -0,0 +1 @@
>> >> +define(`IOCTLTEST', `0x7704')
>> >> diff --git a/sepolicy/surfaceflinger.te b/sepolicy/surfaceflinger.te
>> >> new file mode 100644
>> >> index 000..7c337a9
>> >> --- /dev/null
>> >> +++ b/sepolicy/surfaceflinger.te
>> >> @@ -0,0 +1 @@
>> >> +allow surfaceflinger surfaceflinger:unix_stream_socket { IOCTLTEST };
>> >> diff --git a/sepolicy/system_server.te b/sepolicy/system_server.te
>> >> new file mode 100644
>> >> index 000..218a8a2
>> >> --- /dev/null
>> >> +++ b/sepolicy/system_server.te
>> >> @@ -0,0 +1 @@
>> >> +allow system_server system_server:unix_stream_socket { IOCTLTEST };
>> >> 11:29:19 liuyq: hikey$
>> >>
>> >>
>> >> but how should I find the real name for the ioctlcmd=7704?
>> >> searched in kernel, and found 7704 is defined ad following:
>> >> kernel/linaro/hisilicon/drivers/gpu/drm/radeon/r600d.h:1219:#define
>> HDMI1_STATUS 0x7704
>>
>> iirc the ioctlcmd prints as base 10 not hex. Is that correct Jeff?
>>
>> >>
>> >> but it does not seem to be used for ioctl command.
>> >>
>> >> --
>> >> Best Regards,
>> >> Yongqin Liu
>> >> ---
>> >> #mailing list
>> >> linaro-andr...@lists.linaro.org
>> >> http://lists.linaro.org/mailman/listinfo/linaro-android
>> >> ___
>> >> Seandroid-list mailing list
>> >> Seandroid-list@tycho.nsa.gov
>> >> To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
>> >> To get help, send an email containing "help" to
>> seandroid-list-requ...@tycho.nsa.gov.
>> >
>> >
>> > ___
>> > Seandroid-list mailing list
>> > Seandroid-list@tycho.nsa.gov
>> > To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
>> > To get help, send an email containing "help" to
>> seandroid-list-requ...@tycho.nsa.gov.
>>
>
--
Best Regards,
Yongqin Liu
---
#mailing list
linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
___
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
ioctlcmd=7704 denied on unix_stream_socket for surfaceflinger and system_server domain
Hi, All
When I update to use tag android-6.0.1_r55, I got following avc denials
during the boot up:
avc: denied { ioctl } for pid=177 comm="Binder_2" path="socket:[10083]"
dev="sockfs" ino=10083 ioctlcmd=7704 scontext=u:r:surfaceflinger:s0
tcontext=u:r:surfaceflinger:s0 tclass=unix_stream_socket permissive=0
and
avc: denied { ioctl } for pid=465 comm="Binder_1" path="socket:[14454]"
dev="sockfs" ino=14454 ioctlcmd=7704 scontext=u:r:system_server:s0
tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
With following rules I can make the denials disappeared:
11:29:17 liuyq: hikey$ git diff --staged
diff --git a/sepolicy/ioctl_macros b/sepolicy/ioctl_macros
new file mode 100644
index 000..398976c
--- /dev/null
+++ b/sepolicy/ioctl_macros
@@ -0,0 +1 @@
+define(`IOCTLTEST', `0x7704')
diff --git a/sepolicy/surfaceflinger.te b/sepolicy/surfaceflinger.te
new file mode 100644
index 000..7c337a9
--- /dev/null
+++ b/sepolicy/surfaceflinger.te
@@ -0,0 +1 @@
+allow surfaceflinger surfaceflinger:unix_stream_socket { IOCTLTEST };
diff --git a/sepolicy/system_server.te b/sepolicy/system_server.te
new file mode 100644
index 000..218a8a2
--- /dev/null
+++ b/sepolicy/system_server.te
@@ -0,0 +1 @@
+allow system_server system_server:unix_stream_socket { IOCTLTEST };
11:29:19 liuyq: hikey$
but how should I find the real name for the ioctlcmd=7704?
searched in kernel, and found 7704 is defined ad following:
kernel/linaro/hisilicon/drivers/gpu/drm/radeon/r600d.h:1219:#define
HDMI1_STATUS 0x7704
but it does not seem to be used for ioctl command.
--
Best Regards,
Yongqin Liu
---
#mailing list
linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
___
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
About dac_override denial on logd
Hi, ALL
I am playing the AOSP master with hikey board, and I get the
following dac_override avc denial on logd command:
avc: denied { dac_override } for pid=1763 comm="logd" capability=1
scontext=u:r:logd:s0 tcontext=u:r:logd:s0 tclass=capability permissive=1
I built the same source for Nexus9 board, and I did not see such
dac_override denial on logd with that Nexus9 board.
Searched "logd" in he device projects for hikey and Nexus9, but did not
find any clue on that
why I got the dac_override avc denial on logd with the hikey build,
Referenced the document here:
http://source.android.com/security/selinux/device-policy.html#granting_the_dac_override_capability
But still have no idea how to change to eliminate the dac_override denial
for logd command.
Do you have any idea on what happens there, or where to check on it?
Thanks in advance!
--
Best Regards,
Yongqin Liu
---
#mailing list
linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
___
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
Re: About the tracefs support on Android
On 20 April 2016 at 00:45, Stephen Smalley <s...@tycho.nsa.gov> wrote: > On 04/19/2016 12:32 PM, YongQin Liu wrote: > > Hi, Stephen > > > > Thanks for you suggestions! > > > > With hack on selinux_is_sblabel_mnt(), and sepolicy rules change here: > > https://android-review.googlesource.com/#/c/216878/ > > > > I can make there no avc denials in dmesg. > > but if we support tracefs in the sepolicy rules of AOSP, then kernel is > > required to be 4.1 and later, > > or tracefs feature porting to kernel before that, which seems not > flexible. > > > > is there a better way to make one copy sepolicy rules in AOSP to support > > both kernel versions before 4.1 and later? > > Your policy change also loses the distinction between trace_marker and > other files under tracing. The distinction is important because we only > want trace_marker to be writable by all, not the rest of the tracefs files. > > The only actual change required to sepolicy is adding a line to > genfs_contexts; you do not need to change the existing types, allow > rules, or file_contexts entries. Just add: > genfscon tracefs / u:object_r:debugfs_tracing:s0 > to genfs_contexts. > > Then it should work seamlessly for any kernel version. > /sys/kernel/debug/tracing/trace_marker files can not be marked as debugfs_trace_marker context, following is the output of ls -Z command: u:object_r:debugfs_tracing:s0 /sys/kernel/debug/tracing/trace_marker Thanks, Yongqin Liu > > As a naming cleanup, one could rename debugfs_tracing to tracefs and > debugfs_trace_marker to tracefs_trace_marker, but that's not really > necessary. One could also provide typealias statements to provide > compatibility with the old names for device policies. > > > -- Best Regards, Yongqin Liu --- #mailing list linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android ___ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
Re: About the tracefs support on Android
Hi, Stephen Thanks for you suggestions! With hack on selinux_is_sblabel_mnt(), and sepolicy rules change here: https://android-review.googlesource.com/#/c/216878/ I can make there no avc denials in dmesg. but if we support tracefs in the sepolicy rules of AOSP, then kernel is required to be 4.1 and later, or tracefs feature porting to kernel before that, which seems not flexible. is there a better way to make one copy sepolicy rules in AOSP to support both kernel versions before 4.1 and later? Thanks, Yongqin Liu On 19 April 2016 at 23:13, Stephen Smalley <s...@tycho.nsa.gov> wrote: > On 04/19/2016 10:57 AM, Stephen Smalley wrote: > > On 04/19/2016 10:47 AM, Stephen Smalley wrote: > >> On 04/19/2016 10:32 AM, YongQin Liu wrote: > >>> Hi, ALL > >>> > >>> I am trying the android-n-preview with kernel4.4, and found the tracefs > >>> is automatically mounted there by kernel, mount options like this: > >>> tracefs on /sys/kernel/debug/tracing type tracefs (rw,relatime) > >>> > >>> And I found avc warnings on the console like this: > >>> [6.840279] init: SELinux: Could not set context for > >>> /sys/kernel/debug/tracing/set_event_pid: Operation not supported on > >>> transport endpoint > >>> > >>> I think it's caused by the following lines in file_contexts file: > >>> /sys/kernel/debug/tracing(/.*)? u:object_r:debugfs_tracing:s0 > >>> /sys/kernel/debug/tracing/trace_marker > u:object_r:debugfs_trace_marker:s0 > >>> > >>> > >>> And seems the tracefs does not support the seclabel mount option, > >>> > >>> So what's the better way to support tracefs in Android? > >>> Seems updating sepolicy rules is an easier way, but what if the kernel > >>> still does not support tracefs yet? > >>> Or do some changes in kernel side on tracefs? > >>> > >>> And tracefs would be supported in the user mode as well I guess. > >> > >> Hmm...we would need to augment the logic in SELinux to support per-file > >> labeling of tracefs via either setxattr or genfs_contexts. The quick > >> fix would be to just add tracefs to the list of whitelisted filesystem > >> types in selinux_is_sblabel_mnt(), but the right fix would be to > >> generalize this logic as described in the last item on the todo list, > >> https://bitbucket.org/seandroid/wiki/wiki/ToDo > > > > Also, you'd need to add an entry to genfs_contexts in the policy to > > define a default label for tracefs files. > > The other question is whether Android could dispense with mounting > debugfs at all and only mount tracefs, as that was one of the > motivations for splitting tracefs from debugfs. > > > -- Best Regards, Yongqin Liu --- #mailing list linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android ___ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
Re: About the euid of su command from APP
On 24 February 2016 at 21:52, Stephen Smalley <s...@tycho.nsa.gov> wrote: > On 02/23/2016 12:14 PM, YongQin Liu wrote: > >> Hi, Stephen >> >> Thanks very much! >> >> With commenting out the prctl(PR_CAPBSET_DROP...) call in >> core/jni/com_android_internal_os_Zygote.cpp, >> now I can run su from AndroidTerm shell. >> >> so it's the 2 prctl calls mentioned in this thread keep from the running >> of su in AndroidTerm app shell. >> >> For the sepolicy rules, I only added following rules in one shell.te file: >> userdebug_or_eng(` >>allow shell su_exec:file x_file_perms; >> ') >> >> Do you think is that excepted? >> Seems no need to change the neverallow self:capability rules in app.te >> you mentioned before. >> >> The android version I am playing version is Marshmallow. >> > Just tried again, here is the new updates: some updates: 1. my build is userdebug version based on marshmallow, in Enforcing mode. 2. no changes related sepolicy. no changes on shell.te domain mentioned above, not changes on the external/sepolicy project 3. 2 prctl changes as mentioned above 4. The application is integrated into the system with android:sharedUserId="android.uid.shell" in the Androidmanifest.xml > > Not sure I follow. First, if SELinux is enforcing, then shell is allowed > no capabilities, so it cannot exercise any root privileges. This only makes sense for user build, right? since there is no su.te in user build, so root privileges commands can not be run from shell domain. As you said below, if in userdebug or eng build, shell is allowed to run root privileges commands like running su from console or adb shell. >> SELinux would prevent the app from using any superuser capabilities even if these restrictions were not in effect (see the neverallow self:capability rules in app.te), And this only makes sense with user build too, right? > Second, in userdebug or eng builds, the rules in su.te are included and > those already define a domain transition from shell to the su domain, so > your rule above is neither necessary nor helpful (your rule merely allows > the su binary be executed within the shell domain, with no change in > SELinux domain/permissions, so it still is not allowed to use any > capabilities, whereas the domain_auto_trans() rule in su.te sets up a > domain transition into the su domain, which is allowed capabilities). > You are right here. without my change on shell.te, I can run su from the AndroidTerm shell too. > Also, commenting out those two prctl() calls obviously leaves your system > insecure and no longer consistent with Android (and presumably would fail > CTS security tests at that point). So that is obviously not a workable > solution for real use. > > Thanks, I know, this is only for study purpose. I did not know prctl has such effects on execve functions before. -- Best Regards, Yongqin Liu --- #mailing list linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android ___ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
Re: About the euid of su command from APP
Hi, Stephen Thanks very much! With commenting out the prctl(PR_CAPBSET_DROP...) call in core/jni/com_android_internal_os_Zygote.cpp, now I can run su from AndroidTerm shell. so it's the 2 prctl calls mentioned in this thread keep from the running of su in AndroidTerm app shell. For the sepolicy rules, I only added following rules in one shell.te file: userdebug_or_eng(` allow shell su_exec:file x_file_perms; ') Do you think is that excepted? Seems no need to change the neverallow self:capability rules in app.te you mentioned before. The android version I am playing version is Marshmallow. Thanks, Yongqin Liu On 23 February 2016 at 21:32, Stephen Smalley <s...@tycho.nsa.gov> wrote: > On 02/23/2016 04:06 AM, YongQin Liu wrote: > >> Here is the output of the commands, any new findings? >> >> shell@flounder:/ $ su >> current_uid=2000, current_euid=0, current_gid=2000, current_egid=2000 >> su: setgid failed: Operation not permitted >> 1|shell@flounder:/ $ cat /proc/self/status >> CapInh: >> CapPrm: >> CapEff: >> CapBnd: >> > > Your bounding set is all-zeroes, so you can't gain any superuser > capabilities. This appears to be due to the prctl(PR_CAPBSET_DROP...) call > in core/jni/com_android_internal_os_Zygote.cpp. > > shell@flounder:/ $ id -Z >> context=u:r:shell:s0 <--is the "Operation not permitted" caused by >> this? if so, should not there be some avc denials in logcat for dmesg? >> shell@flounder:/ $ >> > > You said that SELinux was permissive, so it isn't relevant in this case > (but would indeed deny the capabilities if enforcing, and would generate > avc denials). > > -- Best Regards, Yongqin Liu --- #mailing list linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android ___ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
About the euid of su command from APP
HI, ALL I want to run su command from an Application(the AndroidTerm application) which is specified to run with the shell user, but I found it failed to the su command because the euid is not change to the owner of the su command. Here is the output: shell@flounder:/ $ ls -Z /system/xbin/s sane_schedstat showmapshowslab simpleperf sqlite3 strace stringbenchstringbench64 su shell@flounder:/ $ ls -Z /system/xbin/su -rwsr-x--- root shell u:object_r:su_exec:s0 su shell@flounder:/ $ ls -l /system/xbin/su -rwsr-x--- root shell 10232 2016-02-14 17:05 su shell@flounder:/ $ id uid=2000(shell) gid=2000(shell) groups=2000(shell),1015(sdcard_rw),1023(media_rw),3002(net_bt),3003(inet),3008(net_bt_stack),9997(everybody),42000(u0_a32000) context=u:r:shell:s0 shell@flounder:/ $ su current_uid=2000, current_euid=2000, current_gid=2000, current_egid=2000 su: setgid failed: Operation not permitted 1|shell@flounder:/ $ from the above, you can see the euid output from su command is shell user id, not the root user id. If I run su from adb shell, it will work, The output is like following: shell@flounder:/ $ id uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:su:s0 shell@flounder:/ $ su current_uid=2000, current_euid=0, current_gid=2000, current_egid=2000 root@flounder:/ # I guess the failure from APP has something related SELinux, but I can not find out where makes the euid not chnaged. I tried from APP with Permissive mode, it still fails. Anyone has any idea why the euid is not change when I run from APP? Which source should I check? Thanks in advance! -- Best Regards, Yongqin Liu --- #mailing list linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android ___ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
About the mounton permission on cache_file:dir and storage_file:dir
Hi, All
When I tried the Marshmallow version on our platforms, I got following
warnings:
avc: denied { mounton } for pid=1 comm="init" path="/cache" dev="rootfs"
ino=73 scontext=u:r:init:s0 tcontext=u:object_r:cache_file:s0 tclass=dir
permissive=1
avc: denied { mounton } for pid=1 comm="init" path="/storage" dev="rootfs"
ino=73 scontext=u:r:init:s0 tcontext=u:object_r:storage_file:s0 tclass=dir
permissive=1
To remove this warnings, I need to add following rules into the init.te
file:
allow init cache_file:dir mounton;
allow init storage_file:dir mounton;
but I did not see similar rules added into the init.te file for Nexus9
build(device/htc/flounder/sepolicy/),
and there is no such warnings on the Nexus9 build too.
I am confused on why Nexus9 does not need the mounton rules for init
domain, and does not have the warnings.
Anyone here can help to explain for me or point me where I should check?
Thanks in advance!
--
Best Regards,
Yongqin Liu
---
#mailing list
linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
___
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
Re: About the mounton permission on cache_file:dir and storage_file:dir
Hi, Stephen, Jeffrey
On 21 October 2015 at 05:05, Stephen Smalley <stephen.smal...@gmail.com>
wrote:
> Are you using the initramfs contents as your rootfs,
We are using the initramfs as rootfs.
And our kernel is based on the 3.18 version, and does not applied the patch
here:
https://android-review.googlesource.com/#/c/58360/
Should we apply this patch to our kernel?
Thanks,
Yongqin Liu
> or pivoting to an
> ext4 root filesystem image that you built?
>
> On Tue, Oct 20, 2015 at 10:59 AM, YongQin Liu <yongqin@linaro.org>
> wrote:
> > Hi, All
> >
> > When I tried the Marshmallow version on our platforms, I got following
> > warnings:
> > avc: denied { mounton } for pid=1 comm="init" path="/cache" dev="rootfs"
> > ino=73 scontext=u:r:init:s0 tcontext=u:object_r:cache_file:s0 tclass=dir
> > permissive=1
> > avc: denied { mounton } for pid=1 comm="init" path="/storage"
> dev="rootfs"
> > ino=73 scontext=u:r:init:s0 tcontext=u:object_r:storage_file:s0
> tclass=dir
> > permissive=1
> >
> > To remove this warnings, I need to add following rules into the init.te
> > file:
> > allow init cache_file:dir mounton;
> > allow init storage_file:dir mounton;
> >
> > but I did not see similar rules added into the init.te file for Nexus9
> > build(device/htc/flounder/sepolicy/),
> > and there is no such warnings on the Nexus9 build too.
> >
> > I am confused on why Nexus9 does not need the mounton rules for init
> domain,
> > and does not have the warnings.
> >
> > Anyone here can help to explain for me or point me where I should check?
> >
> > Thanks in advance!
> > --
> > Best Regards,
> > Yongqin Liu
> > ---
> > #mailing list
> > linaro-andr...@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/linaro-android
> >
> > ___
> > Seandroid-list mailing list
> > Seandroid-list@tycho.nsa.gov
> > To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
> > To get help, send an email containing "help" to
> > seandroid-list-requ...@tycho.nsa.gov.
>
--
Best Regards,
Yongqin Liu
---
#mailing list
linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
___
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
Re: About test for SELinux on Android
Hi, Stephen On 7 July 2015 at 20:36, Stephen Smalley s...@tycho.nsa.gov wrote: On 07/06/2015 11:29 PM, YongQin Liu wrote: Hi, ALL About the test for SELinux on Android, except the CTS test, is there any other test like unit test/function test we can run for SELinux on Android? Please let me know if you have any suggestions. Thanks in advance! I don't believe so (there were some unit tests for the SELinuxMMAC functionality but they were eventually abandoned as it was believed that they wouldn't get regular testing unless they were part of the CTS). The individual CTS tests that test Android SELinux settings are described in: http://seandroid.bitbucket.org/RunningtheCTS.html Thanks for the information! will check it. -- Best Regards, Yongqin Liu --- #mailing list linaro-andr...@lists.linaro.org linaro-...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android ___ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing help to seandroid-list-requ...@tycho.nsa.gov.
About test for SELinux on Android
Hi, ALL About the test for SELinux on Android, except the CTS test, is there any other test like unit test/function test we can run for SELinux on Android? Please let me know if you have any suggestions. Thanks in advance! -- Best Regards, Yongqin Liu --- #mailing list linaro-andr...@lists.linaro.org linaro-...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android ___ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing help to seandroid-list-requ...@tycho.nsa.gov.
