Messages in this thread | | | Date | Wed, 7 Jan 2009 13:35:13 -0500 | From | "C. Scott Ananian" <> | Subject | Re: [PATCH] Security: Implement and document RLIMIT_NETWORK. |
| |
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/ )
| |