linux-kernel - Re: [PATCH 3/3] block: add back command filter modification via sysfs

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: <1542347164.100259.32.camel@acm.org>
Date:   Thu, 15 Nov 2018 21:46:04 -0800
From:   Bart Van Assche <bvanassche@....org>
To:     Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org
Cc:     linux-scsi@...r.kernel.org, Hannes Reinecke <hare@...e.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>
Subject: Re: [PATCH 3/3] block: add back command filter modification via
 sysfs

On Sat, 2018-11-10 at 17:35 +0100, Paolo Bonzini wrote:
> +sgio_read_filter (RW)
> +---------------------
> +When read, this file will display a list of SCSI commands (i.e. values of
> +the first byte of a CDB) that are always available for unprivileged users
> +via /dev/bsg, /dev/sgNN, or ioctls such as SG_IO and CDROM_SEND_PACKET.
> +When written, the list of commands will be modified.  The default filter
> +can be restored by writing "default" to the file; otherwise the input should
> +be a list of byte values or ranges such as "0x00-0xff".  In the latter case,
> +instead of replacing the filter completely you can add to the commands,
> +by writing a string that begins with '+', or remove them by writing a
> +string that begins with '-'.
> +
> +sgio_write_filter (RW)
> +----------------------
> +When read, this file will display a list of SCSI commands (i.e. values of
> +the first byte of a CDB) that are available for unprivileged users
> +when the block device is open for writing.  Writing to this file behaves
> +as for sgio_read_filter.

This seems like an unfortunate API choice to me. Let's have a look at the
following SBC commands:
* READ(6);  opcode 08h.
* READ(10); opcode 28h.
* READ(12); opcode A8h.
* READ(16); opcode 88h.
* READ(32); opcode 7fh; service action 0009h.

I do not know any application for which it would be useful to allow some but
not all of these commands. With the proposed interface however users will
have to examine all SCSI opcodes and for each opcode they will have to decide
whether or not it should be allowed. Additionally, for opcodes like 7fh that
represent multiple commands, users will have to decide whether they want to
allow all these commands or none. That's why I think that filtering SCSI
commands based on their CDB is an unfortunate choice. Would it be sufficient
for the use cases you are looking at to group SCSI commands as follows and to
enable/disable these commands per group:
* SCSI command that read information from the medium (e.g. READ) or from the
  controller (e.g. READ CAPACITY).
* SCSI commands that modify information on the medium (e.g. WRITE).
* SCSI commands that modify controller settings (e.g. MODE SELECT or SET
  TARGET PORT GROUPS).

Bart.