問題如下，新增一個 設備 /dev/video8， 在 應用訪問時 log 中 報出 avc: denied， 是 selinux 問題， 初始的 log 如下：
06-17 20:23:09.244 19650 19650 I pool-4-thread-1: type=1400 audit(0.0:530): avc: denied { read } for name="video8" dev="tmpfs" ino=224395 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:video_device:s0 tclass=chr_file permissive=1
06-17 20:23:09.244 19650 19650 I pool-4-thread-1: type=1400 audit(0.0:532): avc: denied { ioctl } for path="/dev/video8" dev="tmpfs" ino=224395 ioctlcmd=5600 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:video_device:s0 tclass=chr_file permissive=1
解決方法：
scontext=u:r:untrusted_app_25:s0:c512,c768
tcontext=u:object_r:video_device:s0
tclass=chr_file
根據這個信息，一般的做法是 在 untrusted_app_25.te 中增加 allow untrusted_app_25 video_device:chr_file { read ioctl }; 現在 android 也自帶了一個 命令 audio2allow -i error.txt （把avc: denied 的log 拷貝出來存成 error.txt）,就可以生成需要增加的語句。但是這樣修改后發現， 編譯時包 neverallow， 是因為 video_device 是已經定義過的設備， 修改已經定義的設備的權限就可能包 neverallow。
libsepol.report_failure: neverallow on line 384 of system/sepolicy/public/app.te (or line 8744 of policy.conf) violated by allow untrusted_app_25 video_device:chr_file { read };
libsepol.check_assertions: 1 neverallow failures occurred
那么，我們怎么修改呢， 可以單獨定義一個設備，在 file_contexts 中定義
/dev/video8 u:object_r:video_usb_device:s0
在 device.te 中定義類型(dev_type 類型的貌似需要以 device 結尾，一開始我定義的 video_device_usb, 編譯報錯)：
type video_usb_device, dev_type;
然后在 untrusted_app_25.te 中 增加：
allow untrusted_app_25 video_usb_device:chr_file rw_file_perms;
理論上 加了 rw_file_perms，這個權限，已經包含了 讀 寫的 全部權限， 但是 實際情況是 還是 有 avc: denied
06-18 11:48:14.459 8709 8709 W com.cloudminds.roboticservice: type=1400 audit(0.0:286): avc: denied { write } for comm=43616D657261205375726661636554 name="video8" dev="tmpfs" ino=88535 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:video_usb_device:s0 tclass=chr_file permissive=0
06-18 11:48:14.979 8709 8709 W com.cloudminds.roboticservice: type=1400 audit(0.0:288): avc: denied { write } for comm=43616D657261205375726661636554 name="video8" dev="tmpfs" ino=88535 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:video_usb_device:s0 tclass=chr_file permissive=0
06-18 11:48:15.489 8709 8709 W com.cloudminds.roboticservice: type=1400 audit(0.0:289): avc: denied { write } for comm=43616D657261205375726661636554 name="video8" dev="tmpfs" ino=88535 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:video_usb_device:s0 tclass=chr_file permissive=0
這個 write 權限還是有問題， 看到 紅色的標記了嗎，正常的情況是沒有 這兩個 c512， c768的。seAndroid 主要采用了兩種強制訪問的方法： TE MLS。 我們經常接觸到的都是 TE。 這個恰好是 MLS 相關的，這個部分比較難理解，詳細的可以讀下面連接的文檔
https://blog.csdn.net/l173864930/article/details/17194899。 我用到的只參考了下面的部分：
在SEAndroid中共定義了三個擁有巨大權限的attribute分別是mlstrustedsubject、mlstrustedobject、unconfineddomain，被分類到mlstrustedsubject的type在充當主體domain是可以越過MLS檢查，被分類到mlstrustedobject的type在充當客體時可以越過MLS檢查，被分到unconfineddomain的type則擁有所有權限可對客體進行任意操作。
在SEAndroid中被分在mlstrustedsubject attribute中的type有adbd、debuggerd、drmserver、init、installd、kernel、mediaserver、netd、surfaceflinger、su、system、vold、zygote。
被分在mlstrustedobject attribute中的type有alarm_device、ashmem_device、binder_device、log_device、mtp_device、nv_device、powervr_device、ptmx_device、null_device、cgroup、sysfs、sysfs_writable、sysfs_writable、sysfs_writable、debugfs、apk_data_file、cache_file、dnsproxyd_socket。
被分在unconfineddomain的type有init、kernel、su。
按照上面的說明，我可以把 untrusted_app_25 類型定義的時候加上 mlstrustedsubject, 但是增加后 編譯報錯，因為 untrusted_app_25 是已經定義好的類型， 再定義會沖突。 那么只能修改 video_usb_device 設備的類型了，這個是我們新建的，可以定義， 在 類型定義中，我增加了 mlstrustedobject， 問題解決。
type video_usb_device, dev_type, mlstrustedobject;