max connections per control group (cgroup)

[Alban Crequy]

On Fri, 08 Aug 2014 08:53:23 -0400
Colin Walters <walters at verbum.org> wrote:

> On Fri, Aug 8, 2014, at 07:01 AM, Alban Crequy wrote:
> > 
> > But then, the max_connections_per_cgroup limit would not provide
> > anything that is not already covered by the existing
> > max_connections_per_user limit.
> 
> There is a subtle difference which is setuid binaries.  Right now a
> malicious person can easily take up all uid 0 owned connections by
> spawning many instances of "pkexec".
> 
> (Debatable whether any setuid binaries using dbus should exist - but
> an interesting point here is that all root-owned processes spawned
> from pkexec would also be restricted by the login slice).

Interesting point about setuid & pkexec, I have not thought about it.

But I managed to block an application from changing cgroup by denying
write access on /sys/fs/cgroup/** with AppArmor. If the cgroup file
system supported extended attributes, the blocking could be also done
with SELinux ("setfattr -n security.selinux").

So I think it is better to look at the whole cgroup path than to look at
the scope. Then, we can limit connections on services in the user
session managed by systemd --user.

> > It also bothers me that if dbus-daemon cuts the cgroup path with
> > depth=2 to get "/user.slice/user-1000.slice", it would be dependent
> > on the way systemd organises the cgroups. Systemd's configuration
> > could change and if dbus-daemon hard-codes depth=2, we will have
> > unforeseen effects.
> 
> Yeah, I would say if we chose to do this, it would be systemd
> specific. Theoretically the right way would be listening to logind,
> which makes the whole thing start to get quite circular... kdbus
> can't come fast enough =)