1 |
Hi there, |
2 |
|
3 |
Not really wanting to make a habit of ideas-only posts, here's another |
4 |
ideas-only post! Apologies if this is well answered somewhere else, |
5 |
but I haven't found anything suitable. |
6 |
|
7 |
Given observations that: |
8 |
(1) A significant part of the Gentoo Hardened project seems to be |
9 |
related to policy-based sandboxing of one kind or another. |
10 |
(2) OpenRC has incorporated cgroups for some time. |
11 |
(3) Fedora has recently begun to distribute the new libvirt-sandbox |
12 |
tool, which despite using the rather clunky* libvirt apparently has |
13 |
lightweight (LXC) support ... see |
14 |
https://www.berrange.com/posts/2012/01/17/building-application-sandboxes-with-libvirt-lxc-kvm/ |
15 |
(announcement) and http://libvirt.org/git/?p=libvirt-sandbox.git |
16 |
(code) |
17 |
(4) Heavier virtualization of server infrastructure is becoming the norm |
18 |
(5) At some point in the future LXC containers should relatively |
19 |
viable as security containers (like now: with user namespace complete |
20 |
in the latest kernel series) |
21 |
(6) Sandboxing is of use not only from a direct |
22 |
access-control/permissions perspective, but also a |
23 |
(availability-challenge related) resource utilization perspective, and |
24 |
that this element is becoming more important with increasing use of |
25 |
virtualization. |
26 |
|
27 |
It might make sense to take a look at the policy types and limitations |
28 |
of various approaches to the problem space in use right now, and where |
29 |
this is all going. |
30 |
|
31 |
Key elements seem to be: |
32 |
(1) Kernel-based RBAC or other security policy toolkits, applying to |
33 |
the system as a whole (excluding app-level policies for the moment). |
34 |
(2) Network virtualization using network namespaces (not excluding |
35 |
the more complex end of the spectrum, eg. Open vSwitch type setups: |
36 |
http://openvswitch.org/) with sandboxing achieved via a combination of |
37 |
network logical segmentation, firewalling policies, etc. |
38 |
(3) General-use sandboxing within build processes (portage, etc.) |
39 |
(4) Execution-time daemon-level sandboxing (SELinux policies, |
40 |
chroots, possible use of containers, etc.) |
41 |
|
42 |
Connecting to all this again, to further complicate matters, and |
43 |
potentially exceptionally useful, is the notion of automated |
44 |
(regression/resource/performance) testing. |
45 |
|
46 |
I can't seem to shake the idea that some group or other (maybe not the |
47 |
hardened project, but definitely of relevance here) could potentially |
48 |
contribute to some combination of: |
49 |
(a) Encouraging OpenRC to implement some form of open daemon-specific |
50 |
policy-integration that enabled sufficiently descriptive policies |
51 |
(such that SELinux, grsec, chroot, LXC, or other security and resource |
52 |
policy-implementation engines could be swapped in and out on a |
53 |
per-daemon basis.) |
54 |
(b) Encouraging Portage to make use of additional sandboxing |
55 |
capabilities, in a pluggable mechanism that matched OpenRC daemon |
56 |
swappable-engine functionality as per (a). |
57 |
(c) Encouraging Portage to make use of automated testing facilities |
58 |
enabled by such a library, with regards to the addition of enhanced |
59 |
policies for the description of network connectivity requirements and |
60 |
other such 'sandbox-external' runtime requirements that ebuilds are |
61 |
presently functionally incapable of specifying. |
62 |
(d) Building a security and resource policy library could be somehow |
63 |
attached to the portage tree in support of points (a) and (b), above. |
64 |
|
65 |
Since (d) is the Gentoo Hardened project's rough domain at present, |
66 |
encouraging some form of integration and extension of existing |
67 |
capabilities, eg. by incorporating requisite virtualized |
68 |
network-environment and extra-sandbox-dependency (eg. external service |
69 |
dependency) parameters, might be useful to ponder. |
70 |
|
71 |
Real world problems that can potentially be (somewhat or completely) |
72 |
automatically resolved but are presently left hanging: |
73 |
- Resource-side (management context: capacity planning, security |
74 |
context: availability) .. any cgroup resource: |
75 |
- Is there a hard limit to the amount of a certain resource (eg. |
76 |
CPU, memory, IO bandwidth, # network interfaces, etc.) to which a |
77 |
given daemon can scale? |
78 |
- What is the ROI profile for additional resources vs. some |
79 |
measurable metric of eg. response time/maximum transactions-per-second |
80 |
scalability? |
81 |
- Is there any benefit in guaranteeing any kind of resource (eg. |
82 |
CPU, memory, IO bandwidth, network bandwidth, etc.) to this daemon? |
83 |
- Security-side |
84 |
- Does killing network connectivity affect the daemon (ie. can I |
85 |
deny network access without issue?) |
86 |
- Training of anomaly-based NIDS (based upon instituting network |
87 |
traffic test-loads on the daemon, assignment of a NIDS virtualized |
88 |
network segment) |
89 |
- Generation of protocol(s) or ports does the daemon require |
90 |
|
91 |
I think Gentoo has the capacity to provide some pretty leading |
92 |
features in this space, with a little more effort. |
93 |
|
94 |
Smiles from the jungles of Zomia, |
95 |
Walter |