Re: [gentoo-hardened] Outlook on sandboxing/virt

[Sven Vermeulen]

It is that "little more effort" that displays the main challenge for us:
resources (human resources) that can contribute on these levels with a
sufficiently continuous stream of dedication/time commitments.

In my real-life job I already tell others that you can only support a
technology if you can name 3 people that are supporting it (with all the
rights and accesses they need). Holidays, sickness or other time
constraints make it that you can't do with less.

The same holds for Gentoo Hardened subprojects.

I welcome all new ideas and suggestions but it would be even more awesome
if they come with people taking initiative to work on them.

Wkr
  Sven
On Mar 4, 2013 5:09 AM, "Walter Stanish" <walter@×××××.sh> wrote:

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