linux-kernel - Re: [PATCH 2/3] kill_pid_info_as_uid: don't use security_task

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: <20080225204207.GA116@tv-sign.ru>
Date:	Mon, 25 Feb 2008 23:42:07 +0300
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Stephen Smalley <sds@...ho.nsa.gov>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Quigley <dpquigl@...ho.nsa.gov>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Eric Paris <eparis@...hat.com>,
	Harald Welte <laforge@...monks.org>,
	Pavel Emelyanov <xemul@...nvz.org>,
	"Serge E. Hallyn" <serue@...ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] kill_pid_info_as_uid: don't use security_task_kill()

On 02/25, Casey Schaufler wrote:
> 
> --- Stephen Smalley <sds@...ho.nsa.gov> wrote:
> 
> > 
> > ...
> > > 
> > > I think we should omit the permission checks completely, the task which
> > does
> > > ioctl(USBDEVFS_SUBMITURB) explicitly asks to send the signal to it, we
> > should
> > > not deny the signal even if the task changes its credentials in any way.
> > 
> > If we are applying checks based on uid/gid to protect suid/sgid
> > programs, then we ought to also invoke the LSM hook to allow protection
> > of other credential-changing transformations, like SELinux context
> > transitions.  You either remove all checking or none, please.  And if
> > all, what's the rationale?
> 
> Perhaps more important to my mind is what lead the developers of
> this code to go to such significant lengths to provide this access
> check in the first place. Why was it considered sufficiently important?
> I concur that it's an ugly bit of hackery, but someone must have felt
> it was necessary or they wouldn't have done it.

Previously, USB used "pid_t pid" as a target for the signal. This pid
could be reused by the completely unrelated process, these checks ensure
that we at least doesn't kill the wrong user in this case.

Now we are using "struct pid", this means that the signal always goes
to the "right" task.

Oleg.

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