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

Rémi Denis-Courmont
2009-01-07T20:53:56Z

Le mercredi 7 janvier 2009 19:48:09 Evgeniy Polyakov, vous avez écrit :
> If setting that rlimit does not require admin priviledges, then it does
> not require to drop this. So it is superuser or admin who does this.
> And exactly the same can be achieved with 'owner' iptables module.

No no no.

There is a huge fundamental difference between setrlimit, prctl(SECCOMP),
set*uid and chroot on the one side, and iptables on the other side: The first
ones are APIs for a process to control its own permission. iptables is an
interface to control the _whole_ system.

In other words, the first ones are usable programmatically. iptables is not,
unless you're willing to assume the kernel only operates one single
userland "software".

>From the perspective of distros and system admins, perhaps SELinux and
iptables are sufficient to address this. But from that of a third-party,
upstream, distro-independent or whatever-you-want-to-call-it software vendor,
they don't quite work due to their centralized nature.

> > As I understand it, Michael is trying to build something similar to
> > SECCOMP, only way less restrictive and way more usable by real-life
> > userland programs.

> Security and unpriveledged setup are mutually impossible cases.

On a high-level, sure. You need a trusted privileged entity somewhere.

But when it comes _specifically_ to "unprivileged" as in "non-root", I believe
there is a use case for something less restrictive than SECCOMP, yet more
restrictive than just being a normal non-root process. Something along the
lines of: cannot debug other processes, cannot send signal to them, cannot
create file descriptors, cannot bind sockets, yet can allocate memory, can
read timers, can read/write from any type of (already opened) file. Or
whatever brighter and more knowledgeable mind than mine could define.

Or can someone prove that there is no set of permissions bigger than those of
SECCOMP that would effectively equate to those of a normal non-privileged
process?

--
Rémi Denis-Courmont