AppArmor

AppArmor 类似于selinux ,主要的作用是设置某个可执行程序的访问控制权限,主要区别就在于apparmor是以路径(path)为基础,而selinux以i节点(inode)为基础

AppArmor是一个高效和易于使用的Linux系统安全应用程序。AppArmor对操作系统和应用程序所受到的威胁进行从内到外的保护,甚至是未被发现的0day漏洞和未知的应用程序漏洞所导致的攻击。AppArmor安全策略可以完全定义个别应用程序可以访问的系统资源与各自的特权。AppArmor包含大量的默认策略,它将先进的静态分析和基于学习的工具结合起来,AppArmor甚至可以使非常复杂的应用可以使用在很短的时间内应用成功

AppArmor ("Application Armor") is a security module for the Linux kernel, released under the GNU General Public License. AppArmor allows the system administrator to associate with each program a security profile that restricts the capabilities of that program. It supplements the traditional Unix discretionary access control (DAC) model by providing mandatory access control (MAC). It was included as of the 2.6.36 version of the mainline Linux kernel. Since 2009, Canonical Ltd. contributes to the ongoing AppArmor development.

In addition to manually specifying profiles, AppArmor includes a learning mode, in which violations of the profile are logged, but not prevented. This log can then be turned into a profile, based on the program's typical behavior.

AppArmor is implemented using the Linux Security Modules (LSM) kernel interface.

AppArmor is offered in part as an alternative to SELinux, which critics consider difficult for administrators to set up and maintain.[1] Unlike SELinux, which is based on applying labels to files, AppArmor works with file paths. Proponents of AppArmor claim that it is less complex and easier for the average user to learn than SELinux.[2] They also claim that AppArmor requires fewer modifications to work with existing systems:[citation needed] for example, SELinux requires a filesystem that supports "security labels", and thus cannot provide access control for files mounted via NFS. AppArmor is filesystem-agnostic.

AppArmor represents one of several possible approaches to the problem of restricting the actions that installed software may take.

The SELinux system generally takes a similar approach to AppArmor. One important difference is that SELinux identifies file system objects by inode number instead of path. This means that, for example, while a file that is inaccessible may become accessible under AppArmor when a hard link is created to it, SELinux would deny access through the newly created hard link.

While there has been considerable debate about which approach is better, there is as yet no strong evidence that either approach is preferable. Discussion about their relative merits often revolves around which approach is more aligned with existing Unix/Linux access control mechanisms, but Unix and Linux use a combination of path-based and inode-based access control. Note also that existing access control mechanisms remain in place with either system.[citation needed]

SELinux and AppArmor also differ significantly in how they are administered and how they integrate into the system.

Introduction

AppArmor is a Mandatory Access Control (MAC) system which is a kernel (LSM) enhancement to confine programs to a limited set of resources. AppArmor's security model is to bind access control attributes to programs rather than to users. AppArmor confinement is provided via profiles loaded into the kernel, typically on boot. AppArmor profiles can be in one of two modes: enforcement and complain. Profiles loaded in enforcement mode will result in enforcement of the policy defined in the profile as well as reporting policy violation attempts (either via syslog or auditd). Profiles in complain mode will not enforce policy but instead report policy violation attempts.

AppArmor is different from some other MAC systems on Linux in that it is path-based, allows for mixing of enforcement and complain mode profiles, uses include files to ease development and has a far lower barrier to entry than other popular MAC systems.

AppArmor is an established technology first seen in Immunix, and later integrated into Ubuntu, Novell/SUSE, and Mandriva. Core AppArmor functionality is in the mainline Linux kernel from 2.6.36 onwards; work is ongoing by AppArmor, Ubuntu and other developers to merge additional AppArmor functionality into the mainline kernel.

Example profile

From /etc/apparmor.d/usr.sbin.tcpdump on Ubuntu 9.04:

#include <tunables/global>

/usr/sbin/tcpdump {
#include <abstractions/base>
#include <abstractions/nameservice>
#include <abstractions/user-tmp> capability net_raw,
capability setuid,
capability setgid,
capability dac_override,
network raw,
network packet, # for -D
capability sys_module,
@{PROC}/bus/usb/ r,
@{PROC}/bus/usb/** r, # for -F and -w
audit deny @{HOME}/.* mrwkl,
audit deny @{HOME}/.*/ rw,
audit deny @{HOME}/.*/** mrwkl,
audit deny @{HOME}/bin/ rw,
audit deny @{HOME}/bin/** mrwkl,
@{HOME}/ r,
@{HOME}/** rw, /usr/sbin/tcpdump r,
}

The above profile for tcpdump demonstrates several properties of AppArmor:

  • profiles are simple text files
  • comments are supported in the profile
  • absolute paths as well as file globbing can be used when specifying file access
  • various access controls for files are present. From the profile we see 'r' (read), 'w' (write), 'm' (memory map as executable), 'k' (file locking), and 'l' (creation hard links). There are others not demonstrated in this profile, including (but not limited to) 'ix' (execute and inherit this profile), 'Px' (execute under another profile, after cleaning the environment), and 'Ux' (execute unconfined, after cleaning the environment)
  • access controls for capabilities are present
  • access controls for networking are present
  • specificity in rule matching, ie the most specific rule matches (eg access to @{HOME}/bin/bad.sh is denied with auditing due to 'audit deny @{HOME}/bin/** mrwkl,' even though general access to @{HOME} is permitted with '@{HOME}/** rw,')

  • include files are supported to ease development and simplify profiles (ie #include <abstractions/base>,#include <abstractions/nameservice>#include <abstractions/user-tmp>)

  • variables can be defined and manipulated outside the profile (#include <tunables/global> with @{PROC} and @{HOME})

  • AppArmor profiles are easy to read and audit

Please see More information below for full details on updating and developing profiles as well as instructions using AppArmor.

AppArmor in Ubuntu

AppArmor support was first introduced in Ubuntu 7.04, and is turned on by default in Ubuntu 7.10 and later. AppArmor confinement in Ubuntu is application specific with profiles available for specific binaries. With each release, more and more profiles are shipped by default, with more planned.

If a profile is not available for an application, users may create a profile and add it to /etc/apparmor.d. If a profile is not defined for a particular binary, the binary is not confined. See More information for details.

apparmor介绍的更多相关文章

  1. 当 tcpdump -w 遇到 Permission denied

    为了定位问题,需要在Linux上使用tcpdump并且保存到文件,遇到了如下问题: tcpdump port 9001 -w xxtcpdump: xx: Permission denied 因为已经 ...

  2. KVM 介绍(8):使用 libvirt 迁移 QEMU/KVM 虚机和 Nova 虚机 [Nova Libvirt QEMU/KVM Live Migration]

    学习 KVM 的系列文章: (1)介绍和安装 (2)CPU 和 内存虚拟化 (3)I/O QEMU 全虚拟化和准虚拟化(Para-virtulizaiton) (4)I/O PCI/PCIe设备直接分 ...

  3. Apparmor——Linux内核中的强制访问控制系统

      AppArmor 因为最近在研究OJ(oline judge)后台的安全模块的实现,所以一直在研究Linux下沙箱的东西,同时发现了Apparmor可以提供访问控制. AppArmor(Appli ...

  4. LXC-Linux Containers介绍

    Linux Containers,Linux的容器,容器嘛,可以想象成一个大的装东西的罐子,罐子口很大,里面可以装很多同样形状,只不过大小不同的小罐子.专业的话,叫做基于容器的操作系统层面的虚拟化技术 ...

  5. Docker学习总结之Run命令介绍

    Docker学习总结之Run命令介绍 本文由Vikings(http://www.cnblogs.com/vikings-blog/) 原创,转载请标明.谢谢! 在使用Docker时,执行最多的命令某 ...

  6. 学习LSM(Linux security module)之三:Apparmor的前世今生和基本使用

    感冒了,感觉一脑子浆糊,真是蛋疼. 先粗略讲一些前置知识. 一:MAC和DAC DAC(Discretionary Access Control),自主访问控制,是最常用的一类访问控制机制,意思为主体 ...

  7. 2.LXC和namespace介绍

    lxc介绍 LXC又名Linux container,是一种虚拟化的解决方案,这种是内核级的虚拟化.(主流的解决方案Xen ,KVM, LXC) Linux Container容器是一种内核虚拟化技术 ...

  8. kvm详细介绍

    KVM详解,太详细太深入了,经典 2016-07-18 19:56:38 分类: 虚拟化 原文地址:KVM详解,太详细太深入了,经典 作者:zzjlzx KVM 介绍(1):简介及安装 http:// ...

  9. ubuntu1604环境下mariadb启动卡住报错和apparmor基本使用

    问题描述:Ubuntu 1604 新环境下使用apt安装的mariadb10版本,结果第二天就起不来了,很是郁闷 启动时会卡住,当时就慌了,这什么情况啊,昨天好好的今天就起不来了,过了一会儿就有返回信 ...

随机推荐

  1. GTK+中的树状列表构件(GtkTreeView)

    GTK+中的树状列表构件(GtkTreeView) GTK+中的树状列表构件(GtkTreeView) 在本章的GTK+程序设计教程中,我们将向大家重点介绍非常常用也有点复杂的构件--GtkTreeV ...

  2. Java笔记(十三)……面向对象III继承(inheritance)

    继承概述 继承概述 多个类中存在相同属性和行为时,将这些内容抽取到单独一个类中,那么多个类无需再定义这些属性和行为,只要继那个类即可. 多个类可以称为子类,单独这个类称为父类或者超类. 子类可以直接访 ...

  3. NOIP2002 字串变换

    题二 字串变换 (存盘名: NOIPG2) [问题描述]: 已知有两个字串 A$, B$ 及一组字串变换的规则(至多6个规则): A1$ -> B1$ A2$ -> B2$ 规则的含义为: ...

  4. BP神经网络分类器的设计

    1.BP神经网络训练过程论述 BP网络结构有3层:输入层.隐含层.输出层,如图1所示. 图1 三层BP网络结构 3层BP神经网络学习训练过程主要由4部分组成:输入模式顺传播(输入模式由输入层经隐含层向 ...

  5. 如果iis的配置文件 applicationHost.config坏掉了, 会在 C:\inetpub\history\ 中存储历史备份。复制过去还原就可以了-摘自网络

    You will usually get the error ‘Configuration file is not well-formed XML’ ‘C:\Windows\system32\inet ...

  6. SIP SDP RTSP RTP RTCP webrtc

    rfc1889  rfc2326  rfc3261  rfc3550  rfc3856  rfc6120. SIP SDP RTSP  RTP RTCP,就像他们出现的顺序一样,他们在实际应用中的启用 ...

  7. 选择一个 HTTP 状态码不再是一件难事 – Racksburg

    原文链接:http://racksburg.com/choosing-an-http-status-code/ 打开双语对照阅读 有什么能比 HTTP 响应状态码更简单呢?页面渲染了吗?好极了,返回  ...

  8. Windows Service中使用Threading.Timer需注意回收

    在Windows Service中使用Threading.Timer时需要注意回收池问题 Threading.Timer是基于线程池的,系统会对其进行垃圾回收. 当Threading.Timer定义在 ...

  9. struts2设置<s:select>默认选中项的方法

    struts2的select标签中,常用的有以下几个属性:(1)struts2中的select 标签中,必须设置的属性只有一个,即是list.(2)select标签的list中必须有值,不然会报错.如 ...

  10. Ubuntu Server 12.04 静态IP简洁配置

    PS:很长时间没使用Ubuntu了,刚才安装个Ubuntu Server 12.04做测试.Ubuntu的网络设置跟Redhat系是不一样的,配置IP时发现跟以前的Ubuntu桌面版本也有所不同,记录 ...