On 09/29/2013 08:56 PM, Ryan Mallon wrote:
> Okay, this was just the simplest solution I could come up with that
> fixed the issue for me. Is that a tentative acked/reviewed-by? :-).
>
> ~Ryan
I'm interested to see if anyone else has alternative ideas, but for now:
Reviewed-by: Dan Rosenberg
--
On 30/09/13 10:41, Dan Rosenberg wrote:
> On 09/29/2013 07:41 PM, George Spelvin wrote:
>>> Right, so the pppd application is actually doing the correct thing.
>> And a CAP_SYSLOG setuid binary that *doesn't* DTRT seems like a more
>> immediate security hole than leaking kernel addresses. After al
On 09/29/2013 07:41 PM, George Spelvin wrote:
>> Right, so the pppd application is actually doing the correct thing.
> And a CAP_SYSLOG setuid binary that *doesn't* DTRT seems like a more
> immediate security hole than leaking kernel addresses. After all
> kptr_restrict is optional precisely becau
> Right, so the pppd application is actually doing the correct thing.
And a CAP_SYSLOG setuid binary that *doesn't* DTRT seems like a more
immediate security hole than leaking kernel addresses. After all
kptr_restrict is optional precisely because the benefit is marginal.
The interesting questio
On 30/09/13 09:15, George Spelvin wrote:
> The basic idea is good, but I'm not sure if this is the correct permission
> check to use.
>
> After all, a setuid program might also want to give filtered access to
> a /proc file with some %pK values.
Yeah. I'm not sure if this will break some applicat
The basic idea is good, but I'm not sure if this is the correct permission
check to use.
After all, a setuid program might also want to give filtered access to
a /proc file with some %pK values.
The fundamental problem is that %pK is using permissions at the time
of the read(), while the general
6 matches
Mail list logo
