max connections per control group (cgroup)

[Alban Crequy]

On Wed, 06 Aug 2014 11:55:20 -0400
Colin Walters <walters at verbum.org> wrote:

> On Wed, Aug 6, 2014, at 10:16 AM, Alban Crequy wrote:
> 
> > With the development of cgroups and systemd, system services and
> > session services start in different cgroups. However, cgroups are
> > not a security boundary: a process can freely be moved from a
> > cgroup to another cgroup by an
> > unprivileged user if the user moving the process is the same as the
> > destination
> > cgroup. 
> 
> I think we should be looking at scopes or services, not the topmost
> cgroup.

The patches were looking at the full path, e.g. something like:
/user.slice/user-1000.slice/user at 1000.service/tracker-miner-fs.service

Should it instead consider the following path?
/user.slice/user-1000.slice/user at 1000.service

> Even if an unprivileged uid was able to migrate within their
> login session, they shouldn't be able to escape their login scope.

Is it really true? The capability to move a process from a source cgroup
to a destination cgroup only depends on the file ownership/permission
of the destination cgroup. Login scopes such as
  /user.slice/user-1000.slice/session-c1.scope
belong to root:root with -rw-r--r-- access, so unprivileged processes
cannot migrate there, but on systems with systemd-managed user
sessions, user services such as
  /user.slice/user-1000.slice/user at 1000.service
belong to the user with -rw-r--r-- so any user process can migrate
there.

> I see no point in connection-per-process because Linux by default
> allows creation of many, many processes per uid.
> 
> (Yes, with systemd you can LimitNProc= for system services, which can
> help significantly if the service is prepared for this, but there's no
> realistic equivalent for desktop login sessions)