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]
Date:   Fri, 16 Nov 2018 10:17:19 -0800
From:   Bart Van Assche <bvanassche@....org>
To:     "Theodore Y. Ts'o" <tytso@....edu>,
        Paolo Bonzini <pbonzini@...hat.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        linux-kernel@...r.kernel.org, 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 0/3] SG_IO command filtering via sysfs

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ