lkml.org 
[lkml]   [2001]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
In article <3B3060C0.B2D368C@idb.hist.no>,
Helge Hafting <helgehaf@idb.hist.no> wrote:
>richard offer wrote:
>>
>> In arch/i386/kernel/ptrace.c there is the following code ...
>>
>> ret = -EPERM;
>> if (pid == 1) /* you may not mess with init */
>> goto out_tsk;
>>
>> What is the rationale for this ? Is this a real security decision or
>> an implementation detail (bad things will happen).
>
>I don't know why they did it, but ptracing init is definitely a added
>security risk. If an intruder can't take over init, then a smart
>init can fight back. Of course most inits aren't that smart, but
>at least they can log problems and such. The intruder can't prevent
>that because init cannot be killed except by booting (which is
>noticeable),
>and it cannot be taken over with ptrace. ptrace could otherwise
>be used to make init exec some other init that doesn't do the
>logging.

You can exec another init anyway. Call 'telinit u' and init will
re-exec itself, so that's not tne reason.

The reason right now is I think that ptrace mucks around with
sibling relations and since init is a special 'father of all
processes' (or is that mother?) that would get the system into
trouble real soon.

Mike.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:55    [W:0.048 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site