On Sat, Mar 10, 2007 at 04:21:01PM -0800, Andrew Morton wrote:
> We'd be needing a changelog for that.
Done; sent separately from this email.
> Please update the procfs documentation.
Done.
> Does the patch also cover /proc/pid/smaps?
Yes, and numa_maps.
Thanks!
--
Kees Cook
-
To
The /proc/pid/ "maps", "smaps", and "numa_maps" files contain sensitive
information about the memory location and usage of processes. Issues:
- maps should not be world-readable, especially if programs expect any
kind of ASLR protection from local attackers.
- maps cannot just be 0400
On Sat, Mar 10, 2007 at 04:21:01PM -0800, Andrew Morton wrote:
> > On Sat, 10 Mar 2007 10:33:41 -0800 Kees Cook <[EMAIL PROTECTED]> wrote:
> > Here's another revision, with both the "can ptrace" and the global /proc
> > knob;
>
> We'd be needing a changelog for that.
>
> Please update the
> On Sat, 10 Mar 2007 10:33:41 -0800 Kees Cook <[EMAIL PROTECTED]> wrote:
> Here's another revision, with both the "can ptrace" and the global /proc
> knob;
We'd be needing a changelog for that.
Please update the procfs documentation.
Does the patch also cover /proc/pid/smaps?
-
To unsubscribe
On Fri, Mar 09, 2007 at 09:01:41PM -0800, Arjan van de Ven wrote:
> >I just don't know what it will break - we're changing things so that user A
> >cannot monitor user B's memory maps. I feel that it's sure to break
> >various people's fancy custom system activity monitoring/logging setups,
>
On Fri, Mar 09, 2007 at 09:01:41PM -0800, Arjan van de Ven wrote:
I just don't know what it will break - we're changing things so that user A
cannot monitor user B's memory maps. I feel that it's sure to break
various people's fancy custom system activity monitoring/logging setups,
and the
On Sat, 10 Mar 2007 10:33:41 -0800 Kees Cook [EMAIL PROTECTED] wrote:
Here's another revision, with both the can ptrace and the global /proc
knob;
We'd be needing a changelog for that.
Please update the procfs documentation.
Does the patch also cover /proc/pid/smaps?
-
To unsubscribe from
On Sat, Mar 10, 2007 at 04:21:01PM -0800, Andrew Morton wrote:
On Sat, 10 Mar 2007 10:33:41 -0800 Kees Cook [EMAIL PROTECTED] wrote:
Here's another revision, with both the can ptrace and the global /proc
knob;
We'd be needing a changelog for that.
Please update the procfs
The /proc/pid/ maps, smaps, and numa_maps files contain sensitive
information about the memory location and usage of processes. Issues:
- maps should not be world-readable, especially if programs expect any
kind of ASLR protection from local attackers.
- maps cannot just be 0400 because
On Sat, Mar 10, 2007 at 04:21:01PM -0800, Andrew Morton wrote:
We'd be needing a changelog for that.
Done; sent separately from this email.
Please update the procfs documentation.
Done.
Does the patch also cover /proc/pid/smaps?
Yes, and numa_maps.
Thanks!
--
Kees Cook
-
To unsubscribe
Andrew Morton wrote:
On Thu, 8 Mar 2007 12:55:25 -0800 Kees Cook <[EMAIL PROTECTED]> wrote:
On Tue, Mar 06, 2007 at 08:22:11PM -0800, Arjan van de Ven wrote:
[Adding Cc:lkml]
How about using a reduced check, as is done for fd and environ? This
would allow root-running system monitors to still
> On Thu, 8 Mar 2007 12:55:25 -0800 Kees Cook <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 06, 2007 at 08:22:11PM -0800, Arjan van de Ven wrote:
> > > [Adding Cc:lkml]
> >
> > > How about using a reduced check, as is done for fd and environ? This
> > > would allow root-running system monitors to
On Tue, Mar 06, 2007 at 08:22:11PM -0800, Arjan van de Ven wrote:
> > How about using a reduced check, as is done for fd and environ? This
> > would allow root-running system monitors to still do their job.
> > Effectively, this changes the test from "is ptracing" to just "can
> > ptrace".
>
On Tue, Mar 06, 2007 at 08:22:11PM -0800, Arjan van de Ven wrote:
How about using a reduced check, as is done for fd and environ? This
would allow root-running system monitors to still do their job.
Effectively, this changes the test from is ptracing to just can
ptrace.
If this
On Thu, 8 Mar 2007 12:55:25 -0800 Kees Cook [EMAIL PROTECTED] wrote:
On Tue, Mar 06, 2007 at 08:22:11PM -0800, Arjan van de Ven wrote:
[Adding Cc:lkml]
How about using a reduced check, as is done for fd and environ? This
would allow root-running system monitors to still do their
Andrew Morton wrote:
On Thu, 8 Mar 2007 12:55:25 -0800 Kees Cook [EMAIL PROTECTED] wrote:
On Tue, Mar 06, 2007 at 08:22:11PM -0800, Arjan van de Ven wrote:
[Adding Cc:lkml]
How about using a reduced check, as is done for fd and environ? This
would allow root-running system monitors to still
On Tue, Mar 06, 2007 at 08:22:11PM -0800, Arjan van de Ven wrote:
> > [Adding Cc:lkml]
>
> > How about using a reduced check, as is done for fd and environ? This
> > would allow root-running system monitors to still do their job.
> > Effectively, this changes the test from "is ptracing" to
On Tue, Mar 06, 2007 at 08:22:11PM -0800, Arjan van de Ven wrote:
[Adding Cc:lkml]
How about using a reduced check, as is done for fd and environ? This
would allow root-running system monitors to still do their job.
Effectively, this changes the test from is ptracing to just can
> [Adding Cc:lkml]
> How about using a reduced check, as is done for fd and environ? This
> would allow root-running system monitors to still do their job.
> Effectively, this changes the test from "is ptracing" to just "can
> ptrace".
>
> If this still isn't considered safe, I'll add the
On Tue, Mar 06, 2007 at 06:59:42PM -0800, Andrew Morton wrote:
> On Tue, 6 Mar 2007 18:13:35 -0800 Kees Cook <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Mar 06, 2007 at 05:56:09PM -0800, Andrew Morton wrote:
> > > On Tue, 6 Mar 2007 17:22:34 -0800
> > > Kees Cook <[EMAIL PROTECTED]> wrote:
> > >
>
On Tue, Mar 06, 2007 at 06:59:42PM -0800, Andrew Morton wrote:
On Tue, 6 Mar 2007 18:13:35 -0800 Kees Cook [EMAIL PROTECTED] wrote:
On Tue, Mar 06, 2007 at 05:56:09PM -0800, Andrew Morton wrote:
On Tue, 6 Mar 2007 17:22:34 -0800
Kees Cook [EMAIL PROTECTED] wrote:
This is a
[Adding Cc:lkml]
How about using a reduced check, as is done for fd and environ? This
would allow root-running system monitors to still do their job.
Effectively, this changes the test from is ptracing to just can
ptrace.
If this still isn't considered safe, I'll add the
Implement the same logic for the checks done on /proc/$pid/mem, but
extend them to /proc/$pid/{maps,smaps,numa_maps}. This means that only
processes and their ptrace parents can read their maps files.
Signed-off-by: Kees Cook <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL
Implement the same logic for the checks done on /proc/$pid/mem, but
extend them to /proc/$pid/{maps,smaps,numa_maps}. This means that only
processes and their ptrace parents can read their maps files.
Signed-off-by: Kees Cook <[EMAIL PROTECTED]>
---
This is a continuation of a much earlier
Implement the same logic for the checks done on /proc/$pid/mem, but
extend them to /proc/$pid/{maps,smaps,numa_maps}. This means that only
processes and their ptrace parents can read their maps files.
Signed-off-by: Kees Cook [EMAIL PROTECTED]
---
This is a continuation of a much earlier
Implement the same logic for the checks done on /proc/$pid/mem, but
extend them to /proc/$pid/{maps,smaps,numa_maps}. This means that only
processes and their ptrace parents can read their maps files.
Signed-off-by: Kees Cook [EMAIL PROTECTED]
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
26 matches
Mail list logo
