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
| ||
|
Date: Thu, 25 Oct 2012 11:00:45 -0700 From: Tejun Heo <tj@...nel.org> To: Paolo Bonzini <pbonzini@...hat.com> Cc: Ric Wheeler <rwheeler@...hat.com>, Petr Matousek <pmatouse@...hat.com>, Kay Sievers <kay@...hat.com>, Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org, "James E.J. Bottomley" <James.Bottomley@...senPartnership.com> Subject: Re: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs) (restoring cc lists) Hey, Paolo. On Thu, Oct 25, 2012 at 09:37:39AM +0200, Paolo Bonzini wrote: > Il 24/10/2012 18:47, Tejun Heo ha scritto: > > So, I'm still not convinced we need to go forward with full > > configurability. All use cases you described can be covered with > > per-class static filters + simple override switch to disable all, > > which would result in a lot simpler implementation w/ much smaller > > userland interface. > > I'm not sure the userland interface would be smaller, and it would be > more complex to get right: > > 1) how do you override the default? ioctl+SCM_RIGHTS or sysfs? Disabling filters if opened by root and tranfering via SCM_RIGHTS would be the simplest interface-wise (there's no new interface at all). Would that be too dangerous security-wise? > 2) do you need to override the default to "no access", "full access" and > "default access", or is a binary knob (default access/full access) > sufficient? Default / full should be enough, no? > 3) what capabilities control the setting? CAP_SYS_RAWIO seems to be a pretty good fit. > > What's the rationale for full configurability? > > Depending on the level of trust you have in your users, there are > different policies that are applicable. Even virtualization could have > a range of choices like "permit only standard operations", "also permit > UNMAP", "also permit persistent reservations", "permit everything > including vendor specific commands" I guess I just feel quite reluctant to expose another rather obscure userland configurable in-kernel filter and at the same time I'm not sure whether this is flexible enough. What if a device is shared by multiple virtual machines which are trusted at different levels? What if we end up actually having to filter cdb contents? I'm not trying to block it at all cost but let's make sure we looked into most possibilities before (re)adding this userland visible interface. Jens, James, what do you guys think? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists