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

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

[richard offer]

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).

Thoughts ?

richard.

-----------------------------------------------------------------------
Richard Offer                          Technical Lead, Trust Technology
"Specialization is for insects"                                     SGI
_______________________________________________________________________

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

[Helge Hafting]

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.  

If you want to debug the init software, consider running it
as a normal processs (not PID 1).  If that is impossible , e.g.
you need a real-life setup, do remove the above test temporarily 
and make an init-debug kernel for this purpose.

Helge Hafting

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

[Miquel van Smoorenburg]

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.

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

[Mike Coleman]

miquels@cistron-office.nl (Miquel van Smoorenburg) writes:
> 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.

Yes.  Ptrace does a sort of fakey reparenting of traced processes, which won't
work correctly with init, since it's its own parent.

Notice that init *is* currently allowed to do a PTRACE_TRACEME, which would
almost certainly cause the system to fail spectacularly.  It's not really a
security problem, since init can do anything anyway, but it does annoy my
aesthetic sensibilities a bit.  (The patch I sent to fix this wasn't
incorporated.)

-- 
Mike Coleman, mkc@mathdogs.com
http://www.mathdogs.com
problem solving, expert software development