max connections per control group (cgroup)

Jon Watte jwatte at gmail.com
Wed Aug 6 09:08:58 PDT 2014


>
> I see no point in connection-per-process because Linux by default allows
> creation of many, many processes per uid.


The per-process limitation would defend against runaway bugs, which are
probably a much more likely risk than someone trying to use dbus as a DoS
vector when they already have the ability to execute arbitrary code on the
system.

Sincerely,

jw





Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas
Jefferson


On Wed, Aug 6, 2014 at 8:55 AM, 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.  Even if an unprivileged uid was able to migrate within their
> login session, they shouldn't be able to escape their login scope.
>
> 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)
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20140806/bc131db7/attachment-0001.html>


More information about the dbus mailing list