On 03.02.2016 12:56, David Herrmann wrote:
However, with Hannes' revised patch, a different DoS attack against
dbus-daemon is possible. Imagine a peer that receives batches of FDs,
but never dequeues them. They will be accounted on the inflight-limit
of dbus-daemon, as such causing messages of in
On 03/02/16 11:56, David Herrmann wrote:
> However, with Hannes' revised patch, a different DoS attack against
> dbus-daemon is possible. Imagine a peer that receives batches of FDs,
> but never dequeues them. They will be accounted on the inflight-limit
> of dbus-daemon, as such causing messages o
From: Linus Torvalds
> Sent: 02 February 2016 20:45
> On Tue, Feb 2, 2016 at 12:32 PM, Hannes Frederic Sowa
> wrote:
> >
> > Unfortunately we never transfer a scm_cookie via the skbs but merely use it
> > to initialize unix_skb_parms structure in skb->cb and destroy it afterwards.
>
> Ok, I obvio
Hi
On Wed, Feb 3, 2016 at 12:36 PM, Simon McVittie
wrote:
> Am I right in saying that the advice I give to D-Bus users should be
> something like this?
>
> * system services should not send fds at all, unless they trust the
> dbus-daemon
> * system services should not send fds via D-Bus that wi
On 03.02.2016 12:36, Simon McVittie wrote:
On 02/02/16 17:34, David Herrmann wrote:
Furthermore, with this patch in place, a process better not pass any
file-descriptors to an untrusted process.
...
Did anyone notify the dbus maintainers of this? They
might wanna document this, if not already
On 02/02/16 17:34, David Herrmann wrote:
> Furthermore, with this patch in place, a process better not pass any
> file-descriptors to an untrusted process.
...
> Did anyone notify the dbus maintainers of this? They
> might wanna document this, if not already done (CC: smcv).
Sorry, I'm not clear f
On 03.02.2016 01:57, Hannes Frederic Sowa wrote:
On 02.02.2016 23:11, Linus Torvalds wrote:
But I'm OK with that patch as is if you prefer it that way (maybe you
want
to use the cred to then test for root separately etc, out maybe there
already was done use of cred as cred that I just missed whe
On 02.02.2016 23:11, Linus Torvalds wrote:
[ sorry for the html mail, I'm out grocery shopping ]
On Feb 2, 2016 13:55, "Hannes Frederic Sowa"
wrote:
I slightly tested the attached patch.
Looks fine. I do wonder: if the only thing we use that "struct cred" for is
to do that ->user lookup, ma
Hi Willy,
On 02.02.2016 21:39, Willy Tarreau wrote:
On Tue, Feb 02, 2016 at 09:32:56PM +0100, Hannes Frederic Sowa wrote:
But "struct pid *" in unix_skb_parms should be enough to get us to
corresponding "struct cred *" so we can decrement the correct counter
during skb destruction.
So:
We inc
On Tue, Feb 02, 2016 at 12:53:20PM -0800, Linus Torvalds wrote:
> On Tue, Feb 2, 2016 at 12:49 PM, Willy Tarreau wrote:
> > On Tue, Feb 02, 2016 at 12:44:54PM -0800, Linus Torvalds wrote:
> >>
> >> Umm. I think the "struct cred" may change in between, can't it?
> >
> > You mean for example in case
On 02.02.2016 21:44, Linus Torvalds wrote:
On Tue, Feb 2, 2016 at 12:32 PM, Hannes Frederic Sowa
wrote:
Unfortunately we never transfer a scm_cookie via the skbs but merely use it
to initialize unix_skb_parms structure in skb->cb and destroy it afterwards.
Ok, I obviously didn't check very c
On Tue, Feb 2, 2016 at 12:49 PM, Willy Tarreau wrote:
> On Tue, Feb 02, 2016 at 12:44:54PM -0800, Linus Torvalds wrote:
>>
>> Umm. I think the "struct cred" may change in between, can't it?
>
> You mean for example in case of setuid() or something like this ?
Yeah. I'd be worried about looking up
On Tue, Feb 02, 2016 at 12:44:54PM -0800, Linus Torvalds wrote:
> On Tue, Feb 2, 2016 at 12:32 PM, Hannes Frederic Sowa
> wrote:
> > But "struct pid *" in unix_skb_parms should be enough to get us to
> > corresponding "struct cred *" so we can decrement the correct counter during
> > skb destructi
On Tue, Feb 2, 2016 at 12:32 PM, Hannes Frederic Sowa
wrote:
>
> Unfortunately we never transfer a scm_cookie via the skbs but merely use it
> to initialize unix_skb_parms structure in skb->cb and destroy it afterwards.
Ok, I obviously didn't check very closely.
> But "struct pid *" in unix_skb_
On Tue, Feb 02, 2016 at 09:32:56PM +0100, Hannes Frederic Sowa wrote:
> But "struct pid *" in unix_skb_parms should be enough to get us to
> corresponding "struct cred *" so we can decrement the correct counter
> during skb destruction.
>
> So:
>
> We increment current task's unix_inflight and
On 02.02.2016 20:29, Linus Torvalds wrote:
On Tue, Feb 2, 2016 at 10:29 AM, Hannes Frederic Sowa
wrote:
Anyway, can someone provide a high-level description of what exactly
this patch is supposed to do? Which operation should be limited, who
should inflight FDs be accounted on, and which rlimi
On Tue, Feb 2, 2016 at 10:29 AM, Hannes Frederic Sowa
wrote:
>>
>> Anyway, can someone provide a high-level description of what exactly
>> this patch is supposed to do? Which operation should be limited, who
>> should inflight FDs be accounted on, and which rlimit should be used
>> on each operati
On 02.02.2016 18:34, David Herrmann wrote:
Hi
On Sun, Jan 10, 2016 at 7:54 AM, Willy Tarreau wrote:
It is possible for a process to allocate and accumulate far more FDs than
the process' limit by sending them over a unix socket then closing them
to keep the process' fd count low.
This change
Hi
On Sun, Jan 10, 2016 at 7:54 AM, Willy Tarreau wrote:
> It is possible for a process to allocate and accumulate far more FDs than
> the process' limit by sending them over a unix socket then closing them
> to keep the process' fd count low.
>
> This change addresses this problem by keeping tra
19 matches
Mail list logo
