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