1.防火墙  
        防火墙是在被保护网络和因特网之间，或者在其他网络之间限制访问的一种部件或一系列部件。  
Linux防火墙系统提供了如下功能：  
    ● 访问控制，可以执行基于地址（源和目标）、用户和时间的访问控制策略，从而可以杜绝非授权的访问，同时保护内部用户的合法访问不受影响。  

    ● 审计，对通过它的网络访问进行记录，建立完备的日志、审计和追踪网络访问记录，并可以根据需要产生报表。  
    ● 抗攻击，防火墙系统直接暴露在非信任网络中，对外界来说，受到防火墙保护的内部网络如同一个点，所有的攻击都是直接针对它的，该点称为堡垒机，因此要求堡垒机具有高度的安全性和抵御各种攻击的能力。  
    ● 其他附属功能，如与审计相关的报警和入侵检测，与访问控制相关的身份验证、加密和认证，甚至VPN等
    iptables和firewall防火墙区别？
        iptables用于过滤数据包，属于网络层防火墙.
    firewall能够允许哪些服务可用，那些端口可用.... 属于更高一层的防火墙。
    firewall的底层是使用iptables进行数据过滤，建立在iptables之上。
    在设置iptables后需要重启iptables，会重新加载防火墙模块，而模块的装载将会破坏状态防火墙和确立的连接。会破坏已经对外提供数据链接的程序。可能需要重启程序。
    firewall是动态防火墙，使用了D-BUS方式，修改配置不会破坏已有的数据链接。
2.PAM机制         
         PAM（Pluggable Authentication Modules）是一套共享库，其目的是提供一个框架和一套编程接口，将认证工作由程序员交给管理员，PAM允许管理员在多种认证方法之间作出选择，它能够改变本地认证方法而不需要重新编译与认证相关的应用程序。  
    PAM的功能包括：  
    ● 加密口令（包括DES以外的算法）；
    ● 对用户进行资源限制，防止DOS攻击； 
    ● 允许随意Shadow口令；  
    ● 限制特定用户在指定时间从指定地点登录；



3.入侵检测系统  
        入侵检测技术是一项相对比较新的技术，很少有操作系统安装了入侵检测工具，事实上，标准的Linux发布版本也是最近才配备了这种工具。尽管入侵检测系统的历史很短，但发展却很快，目前比较流行的入侵检测系统有Snort、Portsentry、 Lids等。 


4.入侵检测系统  
入侵检测技术是一项相对比较新的技术，很少有操作系统安装了入侵检测工具，事实上，标准的Linux发布版本也是最近才配备了这种工具。尽管入侵检测系统的历史很短，但发展却很快，目前比较流行的入侵检测系统有Snort、Portsentry、 Lids等。 


5.安全审计  
        即使系统管理员十分精明地采取了各种安全措施，但还会不幸地发现一些新漏洞。攻击者在漏洞被修补之前会迅速抓住机会攻破尽可能多的机器。虽然Linux不能预测何时主机会受到攻击，但是它可以记录攻击者的行踪。  Linux还可以进行检测、记录时间信息和网络连接情况。这些信息将被重定向到日志中备查。  日志是Linux安全结构中的一个重要内容，它是提供攻击发生的唯一真实证据。因为现在的攻击方法多种多样，所以Linux提供网络、主机和用户级的日志信息
 
6.强制访问控制  
强制访问控制（MAC，Mandatory Access Control）是一种由系统管理员从全系统的角度定义和实施的访问控制，它通过标记系统中的主客体，强制性地限制信息的共享和流动，使不同的用户只能访问到与其有关的、指定范围的信息，从根本上防止信息的失泄密和访问混乱的现象。




本文转自willis_sun 51CTO博客，原文链接：http://blog.51cto.com/willis/1854218，如需转载请自行联系原作者


        
        
                
    

linux安全机制学习


曾经一度想学来着，今天看到一个链接，讲的很好，算是写一下加深印象吧


1 栈溢出保护


在程序编译的时候使用-fno-stack-protector标志来告诉gcc，不以栈溢出保护机制进行编译。如果我们没有指定这一个标志，会发生那个什么？

程序会使用fs:x来进行保护，这个地址指向了一个我们无法看到的随机值，并且fs是一个由内核维护的结构。


如果在GDB中调试的话，在$fs:x下断点，重复看几次，就能发现两次运行时值是不一样的，从而说明，fs中的数据值在每次运行中都是不同的，意味着攻击者不能准确的预测它。那么这个值是如何用来保护栈的呢？


在反汇编函数中可以看到，开头会把这个值拷贝到栈上，位于rbp-x的位置上，这个位置是在局部变量和指令指针之间的。 （译注：此处指返回地址和EBP）之间。这个值被称作金丝雀(“canary”)值，指的是矿工曾利用金丝雀来确认是否有气体泄漏，如果金丝雀因为气体泄漏而中毒死亡，可以给矿工预警。


 与上述情况类似，当栈溢出发生时，金丝雀值将在已保存的指令指针被重写前先挂掉，看汇编代码，会发现在函数的最后会从栈中读那个值与原有值比较，如果这两个值一致，金丝雀（canary）没有被修改，从而认为保存的指令指针也没有被修改，进而允许函数正常的返回。如果金丝雀（canary）的值被修改了，栈溢出发生了，保存的指令指针可能也被修改了，因此不能安全返回，函数会调用__stack_chk_fail函数。这个函数会做些魔术，然后丢出一个错误退出进程。如下所示：



$ ./oldskool `perl -e 'print "A"x80'`

*** stack smashing detected ***: ./oldskool terminated

Aborted (core dumped)


2  NX：不可执行内存

去掉-fno-stack-protector是可以让栈溢出就是取消canary机制。而如果去掉-zexecstack标识，就允许执行栈中的代码了。

系统把需要写入数据的内存标识为可行，把保存指令的内存标识为可执行，但是不会有一块内存被同时表示为可写和可执行的。因此不可能在可执行的地方写入shellcode，也不可能在可写的地方执行shellcode.面对开启了NX保护，一种方式就是写ROP，这个技巧就是使用程序中已经有的代码段，也就是位于可执行文件的.text节里面的代码，使用一种方式把他们链接在一起，使他们看起来shellcode.  如果开启了NX保护，执行栈上的数据就会报段错误



3 ASLR：地址空间随机化

通过在root下执行echo "0" > /proc/sys/kernel/randomize_va_space可以关掉ASLR

ALSR可以保证在每次程序加载的时候他自己和所加载的库文件都会被映射到虚拟地址空间的不同地址处，这就意味着我们不能使用自己在gdb中调试的地址了。因为有可能变成另一个。
注意：在我们调试一个程序的时候，GDB会自动关掉ASLR，但是为了更加真实地看到程序，可以把它打开。

 set disable-randomization off

 在gbd中设置之后，利用i poc map可以看函数映射表，大多数都不一一样，但是还有的模块是一样的。这就是在ASLR被开启的情况下，漏洞仍然可以利用成功的关键原因。



 4 现代栈溢出攻击

 利用金丝雀可以保护程序在溢出的情况下不跳到SIP（指令指针）执行shellcode。但是金丝雀只是放在了SIP的前面，而不是栈中的局部变量里面。但是可以覆盖局部变量。有时候可以覆盖一个函数指针，而这个指针会在未来某一个时刻被执行。也有可能，我们覆盖了一个指针，这个指针指向的内存会在未来被写入用户数据，这样攻击者就可以在任意的位置写入数据了。类似的情形经常会被成功的利用而得到进程的控制权。比如GOT覆写。



具体的实验可以看链接提供的例子。

http://www.codeweblog.com/%E7%BF%BB%E8%AF%91-%E7%8E%B0%E4%BB%A3linux%E7%B3%BB%E7%BB%9F%E4%B8%8A%E7%9A%84%E6%A0%88%E6%BA%A2%E5%87%BA%E6%94%BB%E5%87%BB/

一、引言

1.1、什么是Selinux

Selinux是一种MAC（强制访问控制）安全机制，是对传统DAC（直接访问控制）机制的加强，而非替换，定义传统进程对文件对象的访问权限，如果不满足则无法执行，不管当前是什么用户。

本文下面讲的内容，有安卓源码的小伙伴可以到类似目录（android/device/softwinner/common/）去检索查看Selinux的相关操作。

1.2、为什么提出Selinux

传统的DAC机制缺点：对权限管理太粗矿，只要获取到root权限就能为所欲为；

Selinux的优点：可以把权限管控做得更加细致，即使有root权限也无能为力。

二、Selinux基本要素

2.1、安全上下文

2.1.1、概念

安全上下文就是描述文件或者进程的一种属性。

2.1.2、查看安全上下文的方法

进程上下文：ps -Z，关注进程的domain。

举例：“u:r:init:s0”，其中的init就是domain。

文件上下文：ls -Z，关注文件的type。

举例：“u:object_r:system_file:s0”，其中的system_file就是type。

2.1.3、安全上下文的定义位置

普通文件在file_contexts文件中定义；虚拟文件在genf_contexts文件中定义；属性文件在property_contexs文件中定义；应用配置在seapp_contexts文件中定义。

因为我是Bsp软件工程师，负责的是SOC的驱动部分，所以对于Selinux，上面四种文件改动得比较多的普通文件，所以这里就简单举一个普通文件的安全上下文是如何定义的。



上图中，总共为两个文件定义了安全上下文，可以看到，定义安全上下文的语法：文件位置   标签。

文件位置很好理解，就是这个文件是哪个地方的文件，这里要用绝对路径。

而什么是标签呢？可以看到2.1.2中举的两个例子，“u:r:init:s0”、“u:object_r:system_file:s0”，他们都是标签。一个是进程的标签，一个是文件的标签。而其中的init是进程的domain，system_file是文件的type，init、system_file也就是我们所说的安全上下文。

Selinux 依靠标签来匹配操作和政策（所谓操作和政策，就是在Selinux，允许某个进程操作某个文件，如果未授权，就算是root权限也不行）。

2.2、组

2.2.1、概念

这个组的概念，大家不需要理解的太复杂，其实就是表面意思，作用是将相同类型的文件或者进程集合到一个组里。

就像是Linux中的group，在同一群组下的用户或者文件，享有相同的权限。

使能Selinux，将Selinux编译进内核后，当我们启动开发板，Linux内核被加载进入内存，Selinux就开始运行起来了。Selinux会根据我们为一些文件和进程定义好的标签，给他们打上标签。而那些我们没有为它们定义标签的文件和进程，Selinux会根据自己的规则，为它们打上默认的标签。为了某些同类型的文件，比如/dev/tty这些串口设备文件，我们知道，一块Linux开发板，串口是有很多的，既然是串口，那么它们肯定就应该有着相同的权限，需要将他们归为一个小组。加入我们把它们归为serial_file组，那么就应该把它们的安全上下文，也就是文件的type设置为serial_file。

现在，大家就应该理解什么是组的概念了。

2.2.2、关联类型和属性

从2.2.1我们知道了，像/dev/tty这种串口文件，是属于serial_file这种类型的，那么它们的标签就应该是这样“u:object_r:serial_file:s0”。

说到这里，问题也就来了。在Selinux中，其实是没有serial_file这种类型的，那我们又想用它怎么办呢？

这时候，我们就需要用到关联类型和属性这个概念了。

经过之前的解释，其实大家都知道，所谓类型就是进程和文件的安全上下文，而前面说过，安全上下文就是描述进程和文件的属性。安全上下文这里涉及到的属性呢，可以自己定义，也可以用Selinux定义好的。而关联类型和属性那里的属性呢？则是Selinux自己的标准属性，不需要，也不能让用户来自己定义。

还是以/dev/tty为例。在Selinux中，对/dev下的文件，安全上下文默认设置的都是device这个type。这个时候你想要将这些串口设备文件都放在serial_file这一组，让他们与其他设备文件区分开来，而Selinux中又没有这种类型，那么就需要你将它给定义出来并将它与device这个Selinux自带的属性关联起来了。

自定义类型且关联属性，必须在te文件中，命令：“type type_id, [attribute_id]”，示例：“type serial_file, device;”。

既然可以将自定义类型与属性关联起来，那么非自定义的类型自然也可以和属性关联。比如，你想要让一个文件或者进程拥有多个属性时，就可以将它的安全上下文和一些属性关联起来。命令：“typeattribute type_id atrribute_id”。

2.3、transition（切换）

2.3.1、为什么会有这个

背景：在linux中，子进程会默认继承父进程的属性，子目录会默认继承父目录的属性。

问题：基于以上事实，在某些场景直接继承父对象的属性明显是不合适的，容易造成权限过大、不安全。

为了让新起的进程或新建的文件，归属到它应有的那个组或者type，避免子对象继承父对象的属性而造成的不安全，所以就有了切换这种概念。

注意：系统关键进程或长时间运行的进程，必须进行domain切换，比如netd、installd、vold、zygote等。

2.3.2、如何切换

我们知道，安卓系统所有的进程都是由init派生而来的，所以为了让这些子进程不继承init的权限，就需要让他们进行domain切换，domain切换的意思也就是让他们切换到自己的组，这样它们就会使用自己的权限，而非init进程的权限。示例看下图：



可以看到，图中的vecentekseservice是自定义出来的，并且还和domain这个Selinux自己的标准属性关联起来，然后又用init_daemon_domain这个宏函数，将vecentekseservice这个进程从init的子进程的权限切换到了自己的domain。看到这里，可能大家会有疑惑，这个vecentekseservice不是一个自定义的类型嘛？怎么你又在说进程？其实，上图中的代码，都是在vecentekseservice.te这个文件中的。而在Selinux中，定义相关进程的类型和规则，就是在以它的进程名命名的te文件中进行。

2.4、sepolicy

作用：制定规则，确认进程对文件的访问权限，同样在以它的进程名命名的te文件中定义。

2.4.1、分类

AOSP（安卓开源项目）所定义的通用规则：

所在路径为android/system/sepolicy/。里面的public为公共所有，而private对SOC/OEM不可见。
警告：不要试图修改它，否则会违反Goole CTS测试，连编译都通不过。
SOC/OEM所定义的规则目录：

在android/device/softwinner/common/sepolicy/vendor。
2.4.2、该怎么定义sepolicy规则

语法
模板：rule_name source_type target_type:class per_set。

rule，规则，allow, neverallow, allowaudit(record), dontaudit(don't record)；

source_type，进程的组，也就是进程的domain（可以通过ps -Z查看）；

target_type进程所要操作的文件的type（可以通过ls -Z查看）；

class为target_type的类型，system/sepolicy/private/security_classes中有class的定义，常见的有file，dir等；

per_set，定义的权限，常见的有read , write, ioctrol, create, getattr, getattr等。

练习
假如有这么一条报错信息：“avc: denied { call } for pid=2162 comm="AudioOut_D" scontext=u:r:audioserver:s0 tcontext=u:r:hal_audiocontrol_default:s0 tclass=binder permissive=1”。

安卓系统打开了Selinux之后，遇到权限报错，就是上面这样的格式。

我们先来按照语法，来拆分一下上面的log信息。

rule：allow；

source_type：audioserver；

target_type：hal_audiocontrol_default；

class：binder；

per_set：call。

所以，将它们组合起来，一条完整的规则应该是：“allow audioserver hal_audiocontrol_default：binder call”。

然后我们通过ps -Z找到“audioserver”所属的进程，将这条规则添加到以它进程名命名的te文件中去。

三、sepolicy实战

3.1、两种工作模式

Enforcing：强制模式，遇到权限问题立即返回无法继续执行；

Permissive：宽容模式，遇到权限问题，允许继续执行，并将错误信息打印出来，一般用于调试。

3.2、sepolicy的启动和关闭

3.2.1、编译阶段

在编译阶段启动或者关闭sepolicy，属于静态配置。

要想在编译阶段启动sepolicy，需要在config文件中这么配置：“CONFIG_SECURITY_SELINUX=y”；并且在BoardConfig.mk文件中配置：“BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive”。

3.2.2、启动过程中

在启动过程中启动或者关闭sepolicy，属于动态配置。

要想在这个时候启动或者关闭sepolicy，如果不想重新编译，可以直接修改cmdline。方法：fastboot boot.img -c androidboot.selinux=permissive。

3.2.3、启动完成后

在启动完成后启用或者关闭sepolicy，也属于动态配置。

setenforce [Enforcing|Permissive|1|0]设置模式。

getenforce：查看模式。

注意：此方法会在重启后失效。

3.3、如何判断是否是selinux引起的问题

设置为Permissive模式，如果问题依旧存在则说明是其他问题引起的，如果问题不存在，那就说明是selinux引起的。

3.4、如何抓取selinux的log

如果是安卓系统，我这里一般是使用“logcat | grep avc”。

3.5、如何修改

Selinux导致的问题，十有八九是权限问题，所以，只要你将权限被限制的文件或者进程的权限解开即可。这里，有两种组合规则的方式：

自动：audit2allow -i deny.log。

手动：根据错误日志拆分关键字，然后组合成规则。

这里建议手动解决好一些。

3.5.1、常见问题的处理原则

不要试图修改谷歌定义的规则；

如果遇到跟goole规则冲突的地方，只能选择绕道或者修改设计。

3.5.2、常见问题的问题类型

权限被拒绝，解决方法：补齐该权限。
	
跟AOSP的规则冲突，解决方法：修改进程的domain、修改文件的type、修改设计。
3.5.3、常见问题之新增设备

为新增设备定义具体的标签类型；

为进程添加访问该文件的权限。

3.5.4、新增进程或服务

新建te文件，以进程或服务名字来命名，并将te文件加入编译系统；定义新的domain/type，若有必要需添加transition，增加selinux规则；新建安全上下文，将文件打上标签。

一、引言：
Android是一个基于Linux内核的移动操作系统。Linux是一个支持多用户的系统，Android在Linux内核提供的基于UID和GID的安全机制的基础上，又实现了一套称为Permission的安全机制，本文即来分析一下这两种安全机制


二、Linux的安全机制
Linux是基于UID和GID的安全机制，它包含三个基本角色：用户、进程和文件，如下图所示：



Linux中的每一个用户都分配有一个UID(所有者)，然后所有的用户又按组来进划分，每一个用户组都分配有一个GID(所有者所在用户组)。注意，一个用户可以属于多个用户组，也就是说，一个UID可以对应多个GID。在一个用户所对应的用户组中，其中有一个称为主用户组，其它的称为补充用户组。
Linux中的每一个文件都具有三种权限：Read、Write和Execute。这三种权限又按照用户属性划分为三组：Owner、Group和Other。

Linux中的每一个进程也都关联有一个用户，也就是对应有一个UID
由于每一个用户都对应有一个主用户组，以及若干个补充用户组，因此，每一个进程除了有一个对应的UID之外，还对应有一个主GID，以及若干个Supplementary GIDs。这些UID和GID就决定了一个进程所能访问的文件或者所能调用的系统API。
一个进程的UID是怎么来的呢？在默认情况下，就等于创建它的进程的UID，也就是它的父进程的UID。

Linux的第一个进程是init进程，它是由内核在启动完成后创建的，它的UID是root。然后系统中的所有其它进程都是直接由init进程或者间接由init进程的子进程来创建。所以默认情况下，系统的所有进程的UID都应该是root。但是实际情况并非如此，因为父进程在创建子进程之后，也就是在fork之后，可以调用setuid来改变它的UID。

例如，在PC中，init进程启动之后，会先让用户登录。用户登录成功后，就对应有一个shell进程。该shell进程的UID就会被setuid修改为所登录的用户。之后系统中创建的其余进程的UID为所登录的用户。
SUID
进程的UID除了来自于父进程之外，还有另外一种途径。上面我们说到，Linux的文件有三种权限，分别是Read、Wirte和Execute。其实还有另外一个种权限，叫做SUID。例如，我们对Android手机进行root的过程中，会在里面放置一个su文件。这个su文件就具有SUID权限

一个可执行文件一旦被设置了SUID位，那么当它被一个进程通过exec加载之后，该进程的UID就会变成该可执行文件的所有者的UID。也就是说，当上述的su被执行的时候，它所运行在的进程的UID是root，于是它就具有最高级别的权限，想干什么就干什么。

与SUI类似，文件还有另外一个称为SGID的权限，不过它描述的是用户组。也就是说，一个可执行文件一旦被设置了GUID位，么当它被一个进程通过exec加载之后，该进程的主UID就会变成该可执行文件的所有者的主UID。
现在，小伙伴们应该可以理解Android手机的root原理了吧：一个普通的进程通过执行su，从而获得一个具有root权限的进程。有了这个具有root权限的进程之后，就可以想干什么就干什么了。su所做的事情其实很简单，它再fork另外一个子进程来做真正的事情，也就是我们在执行su的时候，后面所跟的那些参数。由于su所运行在的进程的UID是root，因此由它fork出来的子进程的UID也是root。于是，子进程也可以想干什么就干什么了。

在传统的UNIX以及类UNIX系统中，进程的权限只划分两种：特权和非特权。UID等于0的进程就是特权进程，它们可以通过一切的权限检查。UID不等于0的进程就非特权进程，它们在访问一些敏感资源或者调用一个敏感API时，需要进行权限检查。这种纯粹通过UID来做权限检查的安全机制来粗放了。于是，Linux从2.2开始，从进程的权限进行了细分，称为Capabilities。一个进程所具有Capabilities可以通过capset和prctl等系统API来设置。也就是说，当一个进程调用一个敏感的系统API时，Linux内核除了考虑它的UID之外，还会考虑它是否具有对应的Capability。
以上就是Linux基于UID/GID的安全机制的核心内容。接下来我们再看Android基于Permission的安全机制
三、Android的Permission安全机制
它也有三个角色：apk、signature和permission，如下图所示：


Android的APK经过PackageManagerService安装之后，就相当于Linux里面的User，它们都会被分配到一个UID和一个主GID，而APK所申请的Permission就相当于是Linux里面的Supplementary GID。
我们知道，Android的APK都是运行在独立的应用程序进程里面的，并且这些应用程序进程都是Zygote进程fork出来的。Zygote进程又是由init进程fork出来的，并且它被init进程fork出来后，没有被setuid降权，也就是它的uid仍然是root。按照我们前面所说的，应用程序进程被Zygote进程fork出来的时候，它的UID也应当是root。但是，它们的UID会被setuid修改为所加载的APK被分配的UID。
ActivityManagerService在请求Zygote创建应用程序进程的时候，会将这个应用程序所加载的APK所分配得到的UID和GID（包括主GID和Supplementary GID）都收集起来，并且将它们作为参数传递给Zygote进程。Zygote进程通过执行函数来fork应用程序进程，
Signature
两个作用：

控制哪些APK可以共享同一个UID；
控制哪些APK可以申请哪些Permission。

我们知道，如果要让两个APK共享同一个UID，那么就需要在AndroidManifest中配置android:sharedUserId属性。PackageManagerService在安装APK的时候，如果发现两个APK具有相同的android:sharedUserId属性，那么它们就会被分配到相同的UID。当然这有一个前提，就是这两个APK必须具有相同的Signature。这很重要，否则的话，如果我知道别人的APK设置了android:sharedUserId属性，那么我也在自己的APK中设置相同的android:sharedUserId属性，就可以去访问别人APK的数据了。
除了可以通过android:sharedUserId属性申请让两个APK共享同一个UID之外，我们还可以将android:sharedUserId属性的值设置为“android.uid.system”，从而让一个APK的UID设置为1000。UID是1000的用户是system，系统的关键服务都是运行在的进程的UID就是它。它的权限虽然不等同于root，不过也足够大了。我
Permission
有些Permission，例如INSTALL_PACKAGE，不是谁都可以申请的，必须要具有系统签名才可以，这样就可以控制Suppementary GID的分配，从而控制应用程序进程的权限。具有哪些Permission是具有系统签名才可以申请的。
四、总结
了解了Android的Permission机制之后，我们就可以知道：


Android的APK就相当于是Linux的UID。


Android的Permission就相当于是Linux的GID。


Android的Signature就是用来控制APK的UID和GID分配的。