Re: [PATCH] Security: Implement and document RLIMIT_NETWORK.

["C. Scott Ananian" <cscott@laptop.org>]

On Wed, Jan 7, 2009 at 6:47 AM, Evgeniy Polyakov <zbr@ioremap.net> wrote:
>> +This facility is particularly attractive to security platforms like OLPC
>> +Bitfrost [2] and to isolation programs like Rainbow [3] and Plash [4] because:
>> +  * it integrates well with standard techniques for writing privilege-separated
>> +    Unix programs
>> +  * it's available to unprivileged programs

> It isn't, since it can not set rlimit, and if it can, it still can drop it.

Privilege dropping is voluntary, in the same way that a setuid root
program can voluntarily drop root permissions after it has finished
using them.  (Standard example: apache starts as root to open port 80,
and then drops root by changing uid to www or nobody before it
actually processes requests.)

If I understand correctly, rlimit has both 'hard' and 'soft' limits.
An unpriviledged process can change its soft limit at will, up to the
hard limit, but can only *irrevocably lower* its hard limit. (man 2
setrlimit)

I haven't reviewed the patch to confirm this, but this is how I would
expect RLIMIT_NETWORK functions.  A trusted process like inetd (say)
would accept a network connection and create a file handle.  It would
then fork, drop the hard and soft RLIMIT_NETWORK to 0, and then exec
the untrusted client program.  This would allow the untrusted program
to use the 'trusted' network resource via the open file handle, but
prevent it from (say) leaking sensitive transaction data by making
further connections to some other network resource.  (There are better
use cases than inetd, of course.)

According to man 2 setrlimit, "A child process created via fork(2)
inherits its parent's resource limits.  Resource limits are preserved
across execve(2).".
 --scott

-- 
                         ( http://cscott.net/ )