Re: Why can't I ptrace init (pid == 1) ?

[Miquel van Smoorenburg]

In article <[e-mail]>,
Helge Hafting  <[e-mail]> 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.