linux-kernel - Re: [PATCH v3] scsi: require CAP_SYS_ADMIN to write to procfs interface

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] [day] [month] [year] [list]

Message-ID: <87inejdtbx.fsf@xmission.com>
Date:   Thu, 09 Nov 2017 15:40:18 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Aleksa Sarai <asarai@...e.de>
Cc:     "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
        containers@...ts.linux-foundation.org,
        Valentin Rothberg <vrothberg@...e.com>, cyphar@...har.com,
        stable@...r.kernel.org, <greg@...ah.com>
Subject: Re: [PATCH v3] scsi: require CAP_SYS_ADMIN to write to procfs interface

Aleksa Sarai <asarai@...e.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