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