linux-kernel - Re: [PATCH 0/3] SG_IO command filtering 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]

Date:   Thu, 15 Nov 2018 16:37:34 -0800
From:   Bart Van Assche <bvanassche@....org>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        "Theodore Y. Ts'o" <tytso@....edu>, 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>,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH 0/3] SG_IO command filtering via sysfs

On Fri, 2018-11-16 at 01:26 +0100, Paolo Bonzini wrote:
> Yeah, and there are even already helpers such as
> bpf_get_current_uid_gid.  So that part can be done in a sort-of generic way.
> 
> I can try and do the work, but I'd like some agreement on the design
> first...  For example a more important question is how would the BPF
> filter be attached?  Two possibilities that come to mind are:
> 
> - add it to the /dev/sg* or /dev/sd* struct file(*) via a ioctl, and use
> pass the file descriptor to the unprivileged QEMU after setting up the
> BPF filter, via either fork() or SCM_RIGHTS.  This would be a very nice
> model for privilege separation, but I'm afraid it would not work for
> your use case
> 
> - add BPF programs to cgroups, in the form of a new
> BPF_PROG_TYPE_CGROUP_CDB_FILTER or something like that.  That would also
> work for my usecase, and it seems to be in line with how the network
> guys are doing things.  So it would seem like the way to go.
> 
> Some other details...  Registering the first cgroup-based filter would
> disable the default filter; if multiple filters are attached, the
> outcomes of all filters would be AND-ed, also similarly to how socket
> and sockaddr cgroup BPF works.  Finally, filters would be applied also
> to processes with CAP_SYS_RAWIO, unlike the current filter.
> 
> Needless to say, this would not add special case code, but it would
> still add a substantial amount of code, probably comparable to this series.

All user space interfaces in the Linux kernel for storage that I'm familiar
with not only allow configuration of parameters but also make it easy to
query which parameters have been configured. The existing sysfs and configfs
interfaces demonstrate this. Using BPF to configure SG/IO access has a
significant disadvantage, namely that it is very hard to figure out what has
been configured. Figuring out what has been configured namely requires
disassembling BPF. I'm not sure anyone will be enthusiast about this.

Bart.