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
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