summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/Mandatory_Access_Control.mdwn
blob: b4447b3bccc1ca5af05873d1df79a8d506c110ef (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
Rationale
=========

Using some kind of [[!wikipedia Mandatory Access Control]], such as
GrSecurity, AppArmor or SELinux, would make exploitation of security
issues in bundled software harder.

Possible solutions
==================

AppArmor
--------

See [[contribute/design/application_isolation]].

grsecurity
----------

[homepage](http://grsecurity.net/)

grsecurity, along with more kernel hardening features, provides Role-Based
Access Control. Some of its bonus features are slowly implemented upstream
though (ASLR stack/heap protection, information leakage through the proc and
sys filesystems, ways to disable module loading, etc).

A feature that might be problematic is the "admin role" which is a superuser
(more then root in grsec) that has the ability to modify/(des)activate
grsecurity. How to implement this in a Tails environment, where passwords
aren't that secret? Should users of Tails be able to login in that role, and
if so, how could we provide a way to do so without lower grsec security by
revealing worldwide this password?

Users:

- Hardened Gentoo offers a grsec-enabled kernel. RBAC policy?
- Although Liberte Linux uses PaX (Address space modification protection)
  it does not include grsecurity RBAC feature.

- Work to add a grsec kernel flavour to Debian seems to be stalled:
  [[!debbug 605090]].
- Ubuntu developers [used to actively work](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening)
  to upstream grsec features mainline, but this effort seems to have
  stalled, or rather moved to another employer along with Kees Cook.

SELinux
-------

Developed initially by big brother (NSA).

It is pretty hard to write and maintain policies, but such policies
exist and they can "mostly" be used by different Linux distributions.

Poor support in Debian, improved in Squeeze, does not look like it's
going to improve that much.

- <http://etbe.coker.com.au/2012/06/17/debian-selinux-june-2012/>
- <http://etbe.coker.com.au/2010/07/25/se-linux-status-squeeze/>
- selinux policies are part of Squeeze
- GNOME, policykit, etc. are supported by Debian-packaged policies,
  but who is actually using them to confirm they work well?

Smack
-----

The Smack MAC LSM is part of the Linux kernel
([homepage](http://schaufler-ca.com/), [[!wikipedia
Simplified_Mandatory_Access_Control_Kernel]]). It does not seem to be
used by any GNU/Linux distribution out there.

TOMOYO Linux
------------

Some (MAC for files) of the TOMOYO Linux LSM
([homepage](http://tomoyo.sourceforge.jp/)) was mainlined in 2.6.30;
more of it was merged in 2.6.34 and 2.6.36.

It is compiled into Debian Squeeze's kernel.

The out-of-tree patch has far more features, see the [comparison of
versions](http://tomoyo.sourceforge.jp/comparison.html.en) for
details.

A "tomoyo learning daemon" is actually being developed by a third party :
[tomld](http://log69.com/tomld_en.html), might be worst having a look and test it.

For informations on the ongoing tests of this solution, see the
[[tomoyo|Mandatory_Access_Control/tomoyo]] subpage.

RSBAC
-----

RSBAC is a Rule Set Based Access Control. It has a lot of other features. It's
just a patch to the linux kernel, and probably won't be integrated upstream.
Seems no distributions did integrate it or provide easy ways to do so.

Ubuntu has a [package](http://packages.ubuntu.com/search?keywords=rsbac-admin) of the rsbac-admin utility.

- <https://rsbac.m-privacy.de/>
- <http://www.rsbac.org/doc/media/linux-kongress/linux-kongress.html>

Resources
=========

- <https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening>
- <https://wiki.ubuntu.com/SecurityTeam/Roadmap>
- [Comparing SELinux/AppArmor/GRSecurity](http://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html)
- [Another comparison from gentoo](http://www.gentoo-wiki.info/Access_Control_Comparison_Table)
- [yet another comparison](http://elinux.org/Mandatory_Access_Control_Comparison)
- [An exploit that was able to bypass SELinux and AppArmor protections](http://lwn.net/Articles/341773/) by the author
  of grsecurity, which was safe.