Gentoo Archives: gentoo-hardened

From: Walter Stanish <walter@×××××.sh>
To: gentoo-hardened@l.g.o
Subject: [gentoo-hardened] Outlook on sandboxing/virt
Date: Mon, 04 Mar 2013 04:08:57
Message-Id: CACwuEiMXMS-y8jq=qsQSo+=1_ciaMPFMiC+Ru2uWyB+ty_7tBQ@mail.gmail.com
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

Replies

Subject Author
Re: [gentoo-hardened] Outlook on sandboxing/virt Sven Vermeulen <sven.vermeulen@××××××.be>