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: Fri, 13 Oct 2017 15:18:32 +0100 From: Alan Cox <gnomes@...rguk.ukuu.org.uk> To: <Mario.Limonciello@...l.com> Cc: <dvhart@...radead.org>, <andy.shevchenko@...il.com>, <linux-kernel@...r.kernel.org>, <platform-driver-x86@...r.kernel.org>, <luto@...nel.org>, <quasisec@...gle.com>, <pali.rohar@...il.com>, <rjw@...ysocki.net>, <mjg59@...gle.com>, <hch@....de>, <greg@...ah.com> Subject: Re: [PATCH v7 10/15] platform/x86: dell-smbios: add filtering capability for requests > Within Linux the security model is that items accessible through this interface > are only accessible by root. "root" has not been a security concept in the Linux kernel since about 2.0. If you are relying on file permissions then at best you are using CAP_SYS_DAC which is too weak for this. If you are allowing near unchecked communication with a third party entity that the user doesn't trust too much you should be requiring CAP_SYS_RAWIO. In fact it's a fair argument hat if you require CAP_SYS_RAWIO and have a module option you have to set to allow it that with the module loaded with say insmod dell_smbios factory=1 does even blacklisted stuff then you are ok, because a process with CAP_SYS_RAWIO has enough power to totally own the machine anyway including taking over and doing the WMI call itself by hand in user space or loading its own module. Alan
Powered by blists - more mailing lists