From: Bart Van Assche <bvanassche@acm.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>, Paolo Bonzini <pbonzini@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
Hannes Reinecke <hare@suse.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [PATCH 0/3] SG_IO command filtering via sysfs
Date: Fri, 16 Nov 2018 10:17:19 -0800 [thread overview]
Message-ID: <1542392239.100259.52.camel@acm.org> (raw)
In-Reply-To: <20181116174352.GH20617@thunk.org>
On Fri, 2018-11-16 at 12:43 -0500, Theodore Y. Ts'o wrote:
> I'd argue that a purpose-built eBPF access control facility is
> superior to the security_file_ioctl() LSM hook because it can make
> available to the authorization function access to the cached results
> of the SCSI INQUIRY command, and it avoids needing to duplicate
> knowledge of how to parse the parameters of the SG_IO ioctl in the LSM
> module as well as in the SCSI stack.
If an eBPF program would decide which SG_IO commands will be executed
and which ones not, does that mean that a SCSI parser would have to be
implemented in eBPF? If so, does that mean that both the eBPF and the
LSM approach share the disadvantage of requiring to do SCSI CDB parsing
outside the SCSI core?
Bart.
next prev parent reply other threads:[~2018-11-16 18:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-10 16:35 [PATCH 0/3] SG_IO command filtering via sysfs Paolo Bonzini
2018-11-10 16:35 ` [PATCH 1/3] block: add back queue-private command filter Paolo Bonzini
2018-11-10 16:35 ` [PATCH 2/3] scsi: create an all-one filter for scanners Paolo Bonzini
2018-11-10 16:35 ` [PATCH 3/3] block: add back command filter modification via sysfs Paolo Bonzini
2018-11-16 5:46 ` Bart Van Assche
2018-11-16 7:00 ` Paolo Bonzini
2018-11-16 14:42 ` Bart Van Assche
2018-11-10 19:05 ` [PATCH 0/3] SG_IO command filtering " Theodore Y. Ts'o
2018-11-11 13:26 ` Paolo Bonzini
2018-11-11 14:14 ` Theodore Y. Ts'o
2018-11-16 0:26 ` Paolo Bonzini
2018-11-16 0:37 ` Bart Van Assche
2018-11-16 7:01 ` Paolo Bonzini
2018-11-16 17:35 ` Theodore Y. Ts'o
2018-11-11 13:14 ` Christoph Hellwig
2018-11-11 13:42 ` Theodore Y. Ts'o
2018-11-12 8:20 ` Christoph Hellwig
2018-11-12 10:17 ` Paolo Bonzini
2018-11-16 9:32 ` Christoph Hellwig
2018-11-16 9:45 ` Paolo Bonzini
2018-11-16 9:48 ` Christoph Hellwig
2018-11-16 17:43 ` Theodore Y. Ts'o
2018-11-16 18:17 ` Bart Van Assche [this message]
2018-11-16 21:08 ` Paolo Bonzini
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=1542392239.100259.52.camel@acm.org \
--to=bvanassche@acm.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=hare@suse.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=pbonzini@redhat.com \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).