mt linux linux手机直装版
linux查看磁盘挂载的三种方法
第一种方法：使用df命令，例如：
复制代码
代码如下:
orientalson:/home# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 15213032 8043668 7169364 53%/
udev 514496 104 514392 1%/dev
/dev/mapper/vg_test-lv_test
511980 32840 479140 7%/home/mt
orientalson:/home#
上面显示的挂载点/home/mt和她挂载的卷不在同一行，使用shell脚本分析非常麻烦。
第二种方法：使用mount命令，mount-l，这种方法的缺陷在于没有卷的大小，但是挂载点和挂载的卷在同一行。例如：
复制代码
代码如下:
orientalson:/home# mount-l
/dev/sda2 on/ type reiserfs(rw,acl,user_xattr) []
proc on/proc type proc(rw)
sysfs on/sys type sysfs(rw)
debugfs on/sys/kernel/debug type debugfs(rw)
udev on/dev type tmpfs(rw)
devpts on/dev/pts type devpts(rw,mode=0620,gid=5)
securityfs on/sys/kernel/security type securityfs(rw)
/dev/mapper/vg_test-lv_test on/home/mt type reiserfs(rw) []
orientalson:/home#
第三种方法：查看文件/etc/mtab。原理是，每新挂载一个卷基本上都会更新这个文件的，那么自然可以通过这个文件来查看挂载点和挂职的卷。这种方法比mount-l稍微清晰了一点，但是，有时候是不可靠的。
复制代码
代码如下:
orientalson:/home# cat/etc/mtab
/dev/sda2/ reiserfs rw,acl,user_xattr 0 0
proc/proc proc rw 0 0
sysfs/sys sysfs rw 0 0
debugfs/sys/kernel/debug debugfs rw 0 0
udev/dev tmpfs rw 0 0
devpts/dev/pts devpts rw,mode=0620,gid=5 0 0
securityfs/sys/kernel/security securityfs rw 0 0
/dev/mapper/vg_test-lv_test/home/mt reiserfs rw 0 0
orientalson:/home#
上面已经说了基本上会更新这个文件，但是并不总是更新这个问题。如果挂载时使用了-n选项，那么/etc/mtab文件里面就不会新挂载卷的信息。
复制代码
代码如下:
orientalson:/home# umount/home/mt
orientalson:/home# mount-n/dev/vg_test/lv_test/home/mt
orientalson:/home# cat/etc/mtab
/dev/sda2/ reiserfs rw,acl,user_xattr 0 0
proc/proc proc rw 0 0
sysfs/sys sysfs rw 0 0
debugfs/sys/kernel/debug debugfs rw 0 0
udev/dev tmpfs rw 0 0
devpts/dev/pts devpts rw,mode=0620,gid=5 0 0
securityfs/sys/kernel/security securityfs rw 0 0
orientalson:/home#
linux的tftp
Linuxtftp命令详解Linuxtftp命令怎么用？
ftp命令用在本机和tftp服务器之间使用TFTP协议传输文件。
TFTP是用来下载远程文件的最简单网络协议，它其于UDP协议而实现。嵌入式linux的tftp开发环境包括两个方面：一是linux服务器端的tftp-server支持，二是嵌入式目标系统的tftp-client支持。因为u-boot本身内置支持tftp-client，所以嵌入式目标系统端就不用配置了。下面就详细介绍一下linux服务器端tftp-server的配置。
语法tftp(选项)(参数)选项-c：指定与tftp服务器连接成功后，立即要执行的指令；-m：指定文件传输模式。可以是ASCII或者Binary；-v：显示指令详细执行过程；-V：显示指令版本信息。参数
主机：指定tftp要联机的tftp服务器的ip地址或主机名。
实例
1、安装tftp服务器
需要安装xinetd、tftp和tftp-server3个软件
如果能上网，通过yum安装：
yuminstallxinetdyuminstalltftpyuminstalltftp-server
如果不能上网，可以直接安装提供的rpm包：
rpm-ivhxinetd-2.3.14-18.fc9.i386.rpmrpm-ivhtftp-0.48-3.fc9.i386.rpmrpm-ivhtftp-server-0.48-3.fc9.i386.rpm
2、配置tftp服务器
修改/etc/xinetd.d/tftp文件，将其中的disable=yes改为disable=no。主要是设置TFTP服务器的根目录，开启服务。修改后的文件如下：
servicetftp{socket_type=dgramprotocol=udpwait=yesuser=rootserver=/usr/sbin/in.tftpdserver_args=-s/home/mike/tftpboot-cdisable=noper_source=11cps=1002flags=IPv4}
说明：修改项，其中path>处可以改为你的tftp-server的根目录，参数-s指定chroot，-c指定了可以创建文件。
3、启动tftp服务器并关闭防火墙
/etc/init.d/iptablesstop//关闭防火墙sudo/sbin/servicexinetdstart或servicexinetdrestart/etc/init.d/xinetdstart
看到启动就可以了
4、查看tftp服务是否开启
netstat-a|greptftp
显示结果为表明服务已经开启，就表明tftp配置成功了。
5、tftp使用
复制一个文件到tftp服务器目录，然后在主机启动tftp软件，进行简单测试。
tftp192.168.1.2tftp>getdownloadfile>tftp>putuploadfile>tftp>q
6、tftp命令用法如下
tftpyour-ip-address
进入TFTP操作：
connect：连接到远程tftp服务器
mode：文件传输模式
put：上传文件
get：下载文件
quit：退出
verbose：显示详细的处理信息
tarce：显示包路径
status：显示当前状态信息
binary：二进制传输模式
ascii：ascii传送模式
rexmt：设置包传输的超时时间
timeout：设置重传的超时时间
help：帮助信息
?：帮助信息
7、如果老是出现“AVCDenial,clickicontoview”的错误，并不能传输文件，需要作如下修改
修改,将SELINUX设定为disable，使用命令让selinux配置文件生效。
8、Busybox中tftp命令的用法
命令格式为：
tftp...host
如果要下载或上传文件的话是一定要用这些option的。
-g表示下载文件(get)-p表示上传文件(put)-l表示本地文件名(localfile)-r表示远程主机的文件名(remotefile)
例如，要从远程主机192.168.1.2上下载embedexpert，则应输入以下命令
tftp-g-rembedexpert192.168.1.2
用linux中做pxe安装系统的时候，出现PXE-E32:TFTPOPentimeout怎么回事？
这是对应的tftpserver没有起来，需要检查dhcp中对tftp的配置是否正确，网络是否连通，tftpserver是否运行正常。
能不能在sd卡上装linux系统？
可以实现的，你可以通过SD卡启动uboot，不过加载内核的话，可以通过tftp下载内核加载；也可以通过nand里面的内核，如果用SD卡内核是不现实的。当你uboot，kernel都启动之后，从SD卡启动系统应该很简单了。
linuxcp命令无法创建普通文件？
答方法如下
1、应该是没有配置tftp服务器，不存在/tftpboot/这个目录。如果不需要tftp服务器的话，可以忽略，也可以将拷贝内核映像。
2、要在同时拷贝多个文件，我们只需要将多个文件用空格隔开。如下示例：$cpfile_1.txtfile_2.txtfile_3.txt/home/pungki/office。
3、要拷贝一个目录的话会有点棘手。你需要添加-r或者-R选项来实现。-r或-R选项表明递归操作。无论该目录是否为空目录，这个选项都是必要的。如下示例：$cp-rdirectory_1/home/pungki/office。
需要注意的一件事，你需要移除在目录名尾部的斜杠。否则你会收到类似的错误信息cp:omittingdirectory‘directory_1/’。
SELinux权限
在了解SELinux之前，我们先来了解一下Linux的两种访问控制策略：DAC和MAC
DAC，自主访问控制（Discretionary Access control）。系统只提供基本的验证,完整的访问控制由开发者自己控制。
DAC将资源访问者分成三类：Owner、Group、Other。
将访问权限也分成三类：read、write、execute
资源针对资源访问者设置不同的访问权限。访问者通常是各个用户的进程，有自己的uid/gid，通过uid/gid和文件权限匹配,来确定是否可以访问。DAC机制下，每一个用户进程默认都拥有该用户的所有权限。
DAC有两个严重问题：
问题一：
因为Root用户是拥有所有权限的，所以DAC对Root用户的限制是无效的。并且在Linux Kernel 2.1以后，Linux将Root权限根据不同的应用场景划分成许多的Root Capabilities,普通用户也可以被设置某个Root Capability。普通用户如果被设置了CAP_DAC_OVERRIDE，也可以绕过 DAC限制。
问题二：
用户进程拥有该用户的所有权限，可以修改/删除该用户的所有文件资源,难以防止恶意软件。
可见，DAC有明显的缺陷，一旦被入侵，取得Root权限的用户进程就可以无法无天，胡作非为，早期android版本就深受其害。
MAC，强制性访问控制（Mandatory Access control）。系统针对每一项访问都进行严格的限制,具体的限制策略由开发者给出。
Linux MAC针对DAC的不足,要求系统对每一项访问,每访问一个文件资源都需要根据已经定义好了的策略进行针对性的验证。系统可以针对特定的进程与特定的文件资源来进行权限的控制。即使是root用户，它所属的不同的进程，并不一定能取得root权限，而得要看事先为该进程定义的访问限制策略。如果不能通过MAC验证，一样无法执行相关的操作。
与DAC相比，MAC访问控制的“主体”变成了“进程”而不是用户。这样可以限制了Root权限的滥用，另外要求对每一项权限进行了更加完整的细化,可以限制用户对资源的访问行为。
SELinux就是目前最好的MAC机制，也是目前的行业标准。
SELinux，安全增强Linux（Security-Enhanced Linux），是由美国国家安全局(NSA)发起,多个非营利组织和高校参与开发的强制性安全审查机制（Mandatory Access control，简称MAC）。SELinux最早于2000年12月采用GPL许可发布。目前，Linux Kernel 2.6及以上的版本都已经集成了SELinux。
SELinux分成三种模式：
Android 5.x及以上强制开启，因此，disabled(关闭)模式并没有什么用了。通常在调试时，我们会启用Permissve(宽容模式),以便尽可能的发现多的问题,然后一次修正。在量产时启用Enfocing mode(强制模式)来保护系统。
查看SELinux模式：adb shell getenforce
设置SELinux模式：adb shell setenforce 1//0是Permissve，1是Enfocing
SELinux的访问控制示意图：
通常我们开发的过程中，就是配置Subject、Object、Security Policy。
SELinux给Linux的所有对象都分配一个安全上下文(Security Context)，描述成一个标准的字符串。
安全上下文的标准格式： user:role:type[:range]
Security Label用来绑定被访问资源和安全上下文，描述它们的对应关系。标准格式为：resource security_context。即：res user:role:type[:range]。这里也可以使用通配符，例如 net.就可以绑定所有以net.开头的属性，除此之外，还有类似正则表达式的*、？等等通配符。Security Label都定义在type_contexts当中，例如file的定义在file_contexts中，service定义在service_contexts中，property定义在property_contexts中。
举例：
file_contexts:
service_contexts:
查看进程安全上下文： ps-AZ。例如，查看Settings进程的安全上下文，ps-AZ| grep settings：
u:r:system_app:s0 system 1381 585 4234504 201072 0 0 S com.android.settings
查看文件安全上下文： ls-Z。例如，查看文件build.prop的安全上下文：
u:object_r:system_file:s0 build.prop
Type Enforcement(TE)是根据Security Context中的 type进行权限审查,审查 subject type对 object type的某个class类型中某种permission是否具有访问权限，是目前使用最为广泛的MAC审查机制,简单易用。
TE控制语句格式: rule_name source_type target_type: class perm_set
Type Enforcement规则说明：
举个例子，logd.te、tombstoned.te中定义的TE规则：
allow logd runtime_event_log_tags_file:file rw_file_perms;
dontaudit domain runtime_event_log_tags_file:file{ open read};
auditallow tombstoned anr_data_file:file{ append write};
neverallow logd{ app_data_file system_data_file}:dir_file_class_set write;
SELinux中每一个进程或者文件都对应一个type,而每一个type都对应有一个或几个attribute。所有常见的attribute定义在以下文件中：
system/sepolicy/public/attributes
system/sepolicy/prebuilts/api/[build version]/public/attributes
system/sepolicy/prebuilts/api/[build version]/private/attributes
其中的[build version]即为android版本号，例如android O为28.0。常见的attribute定义：
Type对应一个或者几个attribute，Type的定义格式：
type type_name, attribute1, attribute2；
Type的定义通常分散在各个te文件中。例如，常用普通文件的type定义在file.te中：
SEAndroid对于不同的资源类型，定义了不同的Class。比如普通的file、socket等等，比如SELinux使用的security,比如针对每个process参数的process等定义相关的class。这些class，每一个class都有相对应的permissions。比如file就有 read, write, create, getattr, setattr, lock, ioctl等等.比如process就有fork, sigchld, sigkill, ptrace, getpgid, setpgid等等。这些相关的class,以及他们具有那些Permissions都定义在以下文件中：
system/sepolicy/private/access_vectors
system/sepolicy/reqd_mask/access_vectors
system/sepolicy/prebuilts/api/版本号/private/access_vectors
例如：
定义完之后，在以下对应的security_classes文件中声明定义的classes。
system/sepolicy/private/security_classes
system/sepolicy/reqd_mask/security_classes
system/sepolicy/prebuilts/api/版本号/private/security_classes
例如：
注意，Classes和Permissions的定义与Kernel中相关API是强相关的，普通用户严禁修改。
在SELinux中,我们通常称一个进程是一个domain,一个进程fork另外一个进程并执行(exec)一个执行档时,我们往往会涉及到domain的切换.比如init进程, SELinux给予了它很大的权限,而它拉起的服务,我们要限制这个服务的权限，于是就涉及到从一个domain切换到另外一个domain,不然默认就使用init进程的domain.
在SELinux里面有专门的一条语法: type_transition statement.
在准备切换前我们先要确保有相关的权限操作：
如下面的demo, init拉起apache并且切换到 apache的domain.
(1).首先，你得让init_t域中的进程能够执行type为apache_exec_t的文件
allow init_t apache_exec_t: file{read getattr execute};
(2).然后，你还得告诉SELinux，允许init_t做DT切换以进入apache_t域
allow init_t apache_t: process transition;
(3).然后，你还得告诉SELinux，切换入口（对应为entrypoint权限）为执行apache_exec_t类型的文件
allow apache_t apache_exec_t: file entrypoint;
(4).最后，Domain Transition
type_transition init_t apache_exec_t: process apache_t;
可以看到，整个domain切换过程写起来非常麻烦。因此，Google为了使用方便,在system/sepolicy/public/te_macros文件中定义了宏：
我们可以使用这些宏来完成domain切换。
举例：
kernel启动init进程切换domain:
domain_auto_trans(kernel, init_exec, init)
init启动netd、vold、zygote、installd切换domain:
init_daemon_domain(netd)
init_daemon_domain(vold)
init_daemon_domain(zygote)
init_daemon_domain(installd)
一个进程创建在一个目录下创建文件时,默认是沿用父目录的Security Context,如果要设置成特定的Label,就必须进行Object Transitions.
同样是使用：type_transition statement.
对应的必须有两个前提条件:
下面是一个demo, ext_gateway_t这个domain在类型为in_queue_t的目录下，创建类型为 in_file_t的文件.
(1).首先，你得让ext_gateway_t对in_queue_t目录具备访问权限
allow ext_gateway_t in_queue_t: dir{ write search add_name};
(2).然后，你还得告诉SELinux，允许ext_gateway_t访问in_file_t的文件
allow ext_gateway_t in_file_t: file{ write create getattr};
(3).最后，Object Transition
type_transition ext_gateway_t in_queue_t: file in_file_t;
同样的，为了方便使用，Google也在system/sepolicy/public/te_macros文件中定义了宏:
使用举例：
file_type_auto_trans(factory, system_data_file, factory_data_file)
android O以前sepolicy集中放在boot image。前面提到SELinux在Android的主要变更历史时，有提到android O开始，Google将system image和 vendor image分离。因此，sepolicy也相应的被分离存放到system image以及 vendor image。与system相关的sepolicy就存放system image,与SoC vendor相关的sepolicy就存放在vendor image。
对于原生AOSP，Google设定了不同的存放目录,以便进行分离,以Google默认的sepolicy为例，sepolicy主目录为/system/sepolicy，我们主要关注三个子目录：
对于不同的平台，不同平台厂商也设定了不同的存放目录，以MTK平台为例：
首先，根据不同的platform共用sepolicy、platform独有、project独有，分为：
对应的，不同版本会导入不同目录下的sepolicy配置
以mt6763平台为例，导入时：
[common]路径为：/device/mediatek/sepolicy
[platfrom]路径为：/device/mediatek/mt6763/sepolicy/
具体的定义在BoardConfig.mk文件中:
然后，basic、bsp、full又可以主要细分为：
Google在system/sepolicy中定义了相关的neverallow规则,对SELinux Policy的更新进行了限制,以防止开发者过度开放权限，从而引发安全问题。并且还会通过CTS测试检测开发者是否有违法相关的规则。
因此，我们需要注意以下几点：
出现SELinux Policy Exception时常见的两种解决方案：
(1).修改对应节点的SELinux Security Label,为特定的Subject，如system_app、platform_app、priv_app，例如Settings，SystemUI等内置APP开启权限,但严禁为untrsted app开启权限。
(2).通过system server service或者 init启动的service读写操作,然后app通过binder/socket等方式连接访问.此类安全可靠,并且可以在service中做相关的安全审查,推荐这种方法.
情景:定义由 init进程启动的service, factory,其对应的执行档是/vendor/bin/factory。
(1).在device/mediatek/mt6763/sepolicy/basic/non_plat目录下创建一个factory.te,然后将te文件加入编译，如放到这种指定目录下不需要额外配置，sytem/sepolicy/Android.mk中定义的build_policy函数会遍历指定目录导入te文件。
(2).在factory.te中定义factory类型，init启动service时类型转换,
type factory, domain;
type factory_exec, exec_type, file_type, vendor_file_type;
init_daemon_domain(factory)
(3).在file_contexts中绑定执行档
/(system/vendor|vendor)/bin/factory u:object_r:factory_exec:s0
(4).根据factory需要访问的文件以及设备,定义其它的权限在factory.te中.
#Purpose: For key and touch event
allow factory input_device:chr_file r_file_perms;
allow factory input_device:dir rw_dir_perms;
情景:添加一个自定义的system property： persist.demo，并为platform_app设置读写权限
(1).在property.te中定义system property类型
type demo_prop, property_type
(2).在property_contexts中绑定system property的安全上下文。
persist.demo u:object_r:demo_prop:s0
(3).在platform_app.te中新增写权限，可以使用set_prop宏。
set_prop(platform_app, demo_prop)
(4).在platform_app.te中新增读权限，可以get_prop宏。
get_prop(platform_app, demo_prop)
情景:有一个设备节点/dev/demo，有一个platform_app进程需要读写这个设备节点。
(1).在device.te中定义device类型
type demo_device dev_type;
(2).在 file_contexts中绑定demo_device
/dev/demo u:object_r:demo_device:s0
(3).在platform_app.te中，允许platform_app使用demo device的权限
allow platform_app demo_device:chr_file rw_file_perms;
情景:有一个扩展的系统服务demo_service供APP调用。
(1).在service.te中定义service类型
type demo_service, app_api_service, system_server_service, service_manager_type;
(2).在service_contexts中绑定service
demo u:object_r:demo_service:s0
(3).在frameworks/base/core/java/android/content/Context.java中定义服务常量
public static final String DEMO_SERVICE="demo";
(4).在frameworks/base/core/java/android/app/SystemServiceRegistry.java中，参照其它系统服务注册demo_service
(5).在frameworks/base/services/java/com/android/server/SystemServer.java中，启动DemoService，添加到service_manager进行管理。
(6).最后一步，参考其它系统服务，实现DemoManager、DemoService，并定义如IDemoService等等的AIDL接口。
情景:一个native service通过init创建一个socket并绑定在/dev/socket/demo,并且允许某些process访问.
(1).在file.te中定义socket的类型
type demo_socket, file_type;
(2).在file_contexts中绑定socket的类型
/dev/socket/demo_socket u:object_r:demo_socket:s0
(3).允许所有的process访问，使用宏unix_socket_connect(clientdomain, socket, serverdomain)
unix_socket_connect(appdomain, demo, demo)
(1).在device/mediatek/mt6763/sepolicy/basic/non_plat目录下创建一个demo.te。
(2).在demo.te中定义demo类型，init启动service时类型转换。并可以根据demo需要访问的文件以及设备,定义其它的权限在demo.te中。
type demo, domain;
type demo_exec, exec_type, file_type;
init_daemon_domain(demo)
(3).绑定执行档 file_context类型
/vendor/bin/demo u:object_r:demo_exec:s0
(4).创建demo的入口执行档demo_exec、并配置相应的权限。
(1).将SELinux调整到Permissive模式复测
使用eng/userdebug版本，adb shell setenforce 0将SELinux模式调整到Permissive模式，然后复测。如果还能复现问题，则与SELinux无关；如果原本很容易复现,而Permissive mode不能再复现,那么就可能与SELinux相关。
(2).查看LOG中是否有标准的SELinux Policy Exception.
在Kernel LOG/ Main Log中查询关键字"avc: denied"看看是否有与目标进程相关的SELinux Policy Exception,并进一步确认这个异常是否与当时的逻辑相关。
一般情况我们在符合Google sepolicy策略及neverallow策略的前提下，根据LOG中的内容，需要什么权限就加什么权限。例如LOG：
2020-03-27 14:11:02.596 1228-1228/com.android.systemui W/FaceIdThread: type=1400 audit(0.0:481): avc: denied{ read} for name="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0
LOG说明如下：
一般我们需要重点关注的是四个：permission、source type、target type、target class
根据这四个就可以配置出的所需要的selinux权限：
allow [source type] [target type]: [target class] [permission]
例1：
03-27 03:45:22.632 2958 2958 W Camera: type=1400 audit(0.0:314): avc: denied{ read} for name="u:object_r:graphics_debug_prop:s0" dev="tmpfs" ino=2649 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:graphics_debug_prop:s0 tclass=file permissive=0
解决方案：
按正常的套公式，应该是这样修改platform_app.te，增加：
allow platform_app graphics_debug_prop:file r_file_perms;
这里我们利用system/sepolicy/te_macros中定义的宏get_prop：
更多相关的宏定义请参考：system/sepolicy/public/te_macros。
所以最终简化后，修改platform_app.te，增加：
get_prop(platform_app, graphics_debug_prop)
例2：
03-27 14:11:02.596 1228-1228/com.android.systemui W/BackThread: type=1400 audit(0.0:481): avc: denied{ read} for name="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0
解决方案：
修改platform_app.te增加：
allow platform_app als_ps_device:chr_file r_file_perms;
(1).不符合neverallow规则或者修改了neverallow规则
编译报错：
neverallow check failed at xxx
CTS测试项failed：
android.cts.security.SELinuxNeverallowRulesTest#testNeverallowRulesXXX
这类问题在android O vendor和system分离之后，尤其容易出现。基本上这类问题都是因为修改或者增加的te配置不符合neverallow规则，导致编译报错。而为了解决编译报错，又修改了neverallow规则，最终在跑CTS时，没法通过相关的测试项。
解决思路：
(2). init进程fork新进程没有做domain切换
CTS测试项failed：
android.security.cts.SELinuxDomainTest# testInitDomain
解决思路：
fork进程时，参考3.4节中做domain切换。
本文主要参考了MTK-Online的Quick-start中《SELinux问题快速分析》的内容，感谢原作者们的辛勤付出。另外，结合源码和自身开发实践，增加了一些自身理解和实践内容。
