process resource control (was Re: How Unix manages processes in userland)

[David Young <dyoung%pobox.com@localhost>]

On Mon, Dec 09, 2013 at 08:26:13AM -0500, Matthew Orgass wrote:
>   In terms of a security properties, I think what I am most looking
> for is to control:
> 
> 1) what gets written to disk, particularly so that stuff I care
> about doesn't get overwritten but also to be able to tell what is
> using disk space and be able to delete stuff that isn't needed when
> the disk fills up (and ideally prevent it from unnecessarily filling
> up in the first place)
> 
> 2) private data should not be removed from my computer without my consent
> 
> 3) preserve a trusted communication path with various levels of
> control software
> 
> 4) get good battery life on mobile devices and still be able to play
> audio and video without skipping
> 
>   With #3, #1 could be implemented as a reliable rollback mechanism.
> #2 is harder, but very important IMO.  Solving #2 is likely to make
> other options available for #1.  Also, in general an application
> like mplayer usually has no need to write to any file at all but
> contains a lot of complex code from a variety of sources, so being
> able to easily and reliably prevent it from doing that ever would
> eliminate a whole class of possible issues (there are still side
> channel issues, of course, and potential issues with whatever i/o
> methods it uses).
> 
>   Networking was never really integrated into the Unix security
> model that much, and being able to revoke any network access for a
> process and its decendents seems like a basic minimal starting point
> to even possibly be able to address #2.
> 
>   #4 has often not been classified as a security issue, but
> unintended sucking of battery life is a DOS attack that can be very
> significant in practice and the control methods needed to deal with
> it are closely related to other security properties.

It sounds like you want to give the user (and his agents: programs)
more fine-grained control over program resources.  I don't
think that these controls are necessarily the same as security
properties/mechanisms/policies.

We can say, we need more control because there are security issues.  Or
we can say, we have security issues because we lack control.  It's more
useful and truthful to say the latter, I think: we lack control over
the resources programs use.  If a program gets to use any of a user's
resources, it gets to use them all, so we have to be very careful what
programs we run.

I think that with good resource control, we will solve more problems
than we will solve with a security mechanism, but we will surely
solve the security problems, too.  For example, I would like for my
NetBSD boxes both to conserve energy and to reduce heat and noise
most of the time, but it does not matter to me if build.sh and its
descendant processes make those boxes noisily draw power and generate
heat.  Really, I would like to grant build.sh unlimited watts, but put
all other processes on an energy budget.  If I had energy budgets for
processes, surely I could run an untrusted program under a strict power
limit?

If I could limit the universe of network 5-tuples for a process, so that
it could not bind(2) arbitrary local addresses or ports, connect(2)
to or send(2) to arbitrary remote hosts, then that would be enough to
implement a lot of useful policies for diagnostics, privacy, etc.

If I also could limit the number of unique disk blocks a program could
use, and the number of pages of virtual memory, and if I could restrict
the directories where it could link or unlink files, then maybe I could
depend on some untrusted program to apply some useful algorithm to its
standard input and write the result on its standard output, or else
crash trying to exceed its power, storage, network, or memory limits.

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981