From: Oleg Nesterov <oleg@tv-sign.ru>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Casey Schaufler <casey@schaufler-ca.com>,
David Quigley <dpquigl@tycho.nsa.gov>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Eric Paris <eparis@redhat.com>,
Harald Welte <laforge@gnumonks.org>,
Pavel Emelyanov <xemul@openvz.org>,
"Serge E. Hallyn" <serue@us.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] kill_pid_info_as_uid: don't use security_task_kill()
Date: Mon, 25 Feb 2008 23:03:28 +0300 [thread overview]
Message-ID: <20080225200328.GA83@tv-sign.ru> (raw)
In-Reply-To: <1203965042.2804.196.camel@moss-spartans.epoch.ncsc.mil>
On 02/25, Stephen Smalley wrote:
>
> On Mon, 2008-02-25 at 20:42 +0300, Oleg Nesterov wrote:
> > kill_pid_info_as_uid() is solely used by drivers/usb/core/. The original
> > "[PATCH] Fix signal sending in usbdevio on async URB completion" commit
> > 46113830a18847cff8da73005e57bc49c2f95a56 was right, but nowadays we use
> > struct pid and this solves most of the addressed problems.
> >
> > It would be nice to use kill_pid_info() instead, but we can't because USB
> > uses .si_code = SI_ASYNCIO which fools SI_FROMUSER() and thus security checks.
> >
> > 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.
Yes, you are right. I'd like to remove all uid/euid checks. This patch doesn't
do this because
- perhaps it will be possible to kill this helper
- if we remove these checks, we should do some subsequent cleanups
in drivers/usb/core/, while this series is all about LSM hooks.
I am going to do this later.
> And if all, what's the rationale?
I think it is not good that LSM has some special (and unneeded!) hacks for USB.
Please also look at the next patch.
Do you agree?
Oleg.
next prev parent reply other threads:[~2008-02-25 20:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-25 17:42 [PATCH 2/3] kill_pid_info_as_uid: don't use security_task_kill() Oleg Nesterov
2008-02-25 18:00 ` Serge E. Hallyn
2008-02-25 18:42 ` Oleg Nesterov
2008-02-25 18:44 ` Stephen Smalley
2008-02-25 20:03 ` Oleg Nesterov [this message]
2008-02-25 22:18 ` Oleg Nesterov
2008-02-25 20:23 ` Casey Schaufler
2008-02-25 20:42 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080225200328.GA83@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=akpm@linux-foundation.org \
--cc=casey@schaufler-ca.com \
--cc=dpquigl@tycho.nsa.gov \
--cc=ebiederm@xmission.com \
--cc=eparis@redhat.com \
--cc=laforge@gnumonks.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=serue@us.ibm.com \
--cc=xemul@openvz.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox