lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1206455835.3302.185.camel@moss-spartans.epoch.ncsc.mil>
Date:	Tue, 25 Mar 2008 10:37:15 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Oleg Nesterov <oleg@...sign.ru>, 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, Chris Wright <chrisw@...s-sol.org>,
	Andrew Morgan <morgan@...nel.org>
Subject: Re: [PATCH] ptrace: it is fun to strace /sbin/init


On Tue, 2008-03-25 at 08:40 -0500, Serge E. Hallyn wrote:
> Quoting Stephen Smalley (sds@...ho.nsa.gov):
> > 
> > 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).
> 
> Still thinking it through, but it seems like special casing init isn't
> useful.  There are likely to be other tasks with all capabilities
> set which the malicious task could just as well ptrace to do his
> mischief, right?

Depends on the bounding set.  Didn't it used to be the case that only
init had CAP_SETPCAP (until the meaning of it was changed by the
filesystem capability support)?

Might want to double check with e.g. the vservers folks that they
weren't relying in any way on special handling of init.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ