[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1206446637.3302.134.camel@moss-spartans.epoch.ncsc.mil>
Date: Tue, 25 Mar 2008 08:03:57 -0400
From: Stephen Smalley <sds@...ho.nsa.gov>
To: Oleg Nesterov <oleg@...sign.ru>
Cc: Pavel Machek <pavel@....cz>,
Andrew Morton <akpm@...ux-foundation.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Pavel Emelyanov <xemul@...nvz.org>,
Roland McGrath <roland@...hat.com>,
linux-kernel@...r.kernel.org, "Serge E. Hallyn" <serue@...ibm.com>,
Chris Wright <chrisw@...s-sol.org>
Subject: Re: [PATCH] ptrace: it is fun to strace /sbin/init
On Tue, 2008-03-25 at 02:04 +0300, Oleg Nesterov wrote:
> On 03/24, Pavel Machek wrote:
> >
> > > /sbin/init is important, but there are other important (and sometimes
> > > much more important) services. Why it is so special so that we can't
> > > debug/strace it?
> >
> > Maybe. Let's kill /sbin/init protection in 2.6.26. But making it
> > optional is wrong.
>
> You are right, the boot parameter is silly. How about sysctl?
>
> Stephen, do you see any security problems if we make /sbin/init
> ptraceable by default?
Not an issue for SELinux (we apply an orthogonal check based on security
context, so we can already block ptrace of init independent of whether
root/CAP_SYS_PTRACE can do it). I'm not sure though as to whether
people using capabilities have ever relied on this special protection of
init (e.g. custom init spawns children with lesser capabilities and
relies on the fact that they cannot ptrace init to effectively re-gain
those capabilities, even if they possess CAP_SYS_PTRACE).
--
Stephen Smalley
National Security Agency
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists