Messages in this thread | | | From | (Miquel van Smoorenburg) | Date | Wed, 20 Jun 2001 08:45:18 +0000 (UTC) |
| |
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/
| |