public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Aleksa Sarai <asarai@suse.de>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	containers@lists.linux-foundation.org,
	Valentin Rothberg <vrothberg@suse.com>,
	cyphar@cyphar.com, stable@vger.kernel.org, <greg@kroah.com>
Subject: Re: [PATCH v3] scsi: require CAP_SYS_ADMIN to write to procfs interface
Date: Thu, 09 Nov 2017 15:40:18 -0600	[thread overview]
Message-ID: <87inejdtbx.fsf@xmission.com> (raw)
In-Reply-To: <b3bcff37-d77d-4dc6-ba83-7dddcb51a703@suse.de> (Aleksa Sarai's message of "Sun, 5 Nov 2017 15:02:10 +1100")

Aleksa Sarai <asarai@suse.de> writes:

> On 11/05/2017 01:56 PM, Aleksa Sarai wrote:
>> Previously, the only capability effectively required to operate on the
>> /proc/scsi interface was CAP_DAC_OVERRIDE (or for some other files,
>> having an fsuid of GLOBAL_ROOT_UID was enough). This means that
>> semi-privileged processes could interfere with core components of a
>> system (such as causing a DoS by removing the underlying SCSI device of
>> the host's / mount).
>
> An alternative to this patch would be to make the open(2) call fail, if you try
> to open it write-only or read-write. Not sure which would be preferred (should
> it be possible to pass /proc/scsi/scsi to a semi-privileged process to write
> to?).

Making open fail is very much the preferred solution.

Testing for permission on write can be avoided by finding a suid root
application whose error output acts like a suid cat.

The best current practice for adding this kind of permission check is to
add the check in open.  For some older use cases where we made this
mistake we had to maintian a check during write to avoid breaking
userspace.  But as this check is new there is no reason to add a check
anywhere except in open.

Eric

  reply	other threads:[~2017-11-09 21:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-05  2:56 [PATCH v3] scsi: require CAP_SYS_ADMIN to write to procfs interface Aleksa Sarai
2017-11-05  4:02 ` Aleksa Sarai
2017-11-09 21:40   ` Eric W. Biederman [this message]
2017-11-05  7:31 ` Greg KH
2017-11-05  9:11   ` Aleksa Sarai
2017-11-05 10:29     ` Greg KH

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=87inejdtbx.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=asarai@suse.de \
    --cc=containers@lists.linux-foundation.org \
    --cc=cyphar@cyphar.com \
    --cc=greg@kroah.com \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=stable@vger.kernel.org \
    --cc=vrothberg@suse.com \
    /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